OK, it could help with the "slowing down" of writes to the fifo... at the cost of double the interrupts... and the "latency" that the ISR brings in (lot of tricks to make it work "normally"... )
But as far as I tested right now, it's the restarting of the SPI transfer that's taking a long time (or the combination of a delay after the transfer is completed and the SPI_USR gets cleared).
If you check the code fragment I posted there is no fifo re-filling going on, just waiting for the SPI_USR flag to clear and immediately restarting the transfer by setting the SPI_USR bit.
Giving the rather "unclear/incomplete" documentation its a kind of "roulette" to make it work as one would "like" or "expect"....
The network part is still "far" for me as if the SPI will not work "sufficently good" there is no point in "loosing more hairs" with the ESP.... even if it's a great solution.
Another question... I noticed the ESP should be capable of high priority interrupts (at least, that's understandable from the .h files included in the RTOS SDK which "shows" some more details).
Any idea of how to make the SPI a high priority interrupt? (to have it's own ISR vector so a lot less latency)