On 12/19/2016 9:40 AM, Stefan Puiu wrote: > Our use case is that we have an app that needs to keep mbufs around > for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from > vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX > descriptors (where it returns -err). Since there are no mbufs that the > virtual hardware can use, no packets will be received after this; the > driver won't refill the mbuf after this so it gets stuck in this > state. I call this a deadlock for lack of a better term - the virtual > HW waits for free mbufs, while the app waits for the hardware to > notify it for data (by flipping the generation bit on the used Rx > descriptors). Note that after this, the app can't recover. > > This fix is a rework of this patch by Marco Lee: > http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port > it, address review comments and also reverted the allocation > failure handling to the first version of the patch > (http://dpdk.org/ml/archives/dev/2015-July/022079.html), since > that's the only approach that seems to work, and seems to be what > other drivers are doing (I checked ixgbe and em). Reusing the mbuf > that's getting passed to the application doesn't seem to make > sense, and it was causing weird issues in our app. Also, reusing > rxm without checking if it's NULL could cause the code to crash. > > Signed-off-by: Stefan Puiu <stefan.p...@gmail.com>
Applied to dpdk-next-net/master, thanks.
