NAK
Doing this risks having a CPU lockup if userspace does not keep up
or the DPDK application gets stuck.
There are better ways to solve the TCP stack queue overrun issue:
1. Use a better queueing discipline on the kni device. The Linux default
of pfifo_fast has bufferbloat issues. Use fq_codel, fq, codel or pie?
2. KNI should implement BQL so that TCP stack can see lock backpressure
about possible queue depth.
Thanks for the suggestions.
I agree that we risk a lockup, in case the DPDK app gets stuck.
Indeed, I am running on an older Linux kernel, and the default queuing discipline is pfifo_fast.
I'll experiment with the queuing disciplines you recommended.
As a simple workaround increase the KNI ring size. It won't solve the whole
problem but i tcan help
I obtained moderate success with increasing MAX_MBUF_BURST_NUM from 32 to 1024 in librte_kni.
I'm not sure if such a change would be upstreamable. Perhaps it needs a bit of testing.
I'll drop the current patch.