[dpdk-dev] can eth_igb_xmit_pkts called with len 0 affect transmission?

[ciprian.barbu <ciprian.barbu@enea.com>]

Hi,

I'm seeing a strange behavior when calling rte_eth_tx_burst with len == 
0. I'll explain the reason for this situation further bellow. But what 
I'm seeing is that after doing this call my application keeps returning 
from eth_igb_xmit_pkts here, even when len > 0: 
http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_e1000/igb_rxtx.c?h=releases#n476

I can't really explain myself this behavior, I don't understand very 
well what the nic does once it receives buffers in its rings, but to me 
it looks like calling rte_eth_tx_burst with len 0 has this effect.

What I'm using in my tests is the linaro odp-dpdk implementation and the 
odp_l2fwd example. The odp-dpdk implementation makes this call to try 
and make the pmd to flush the tx queue in case there are no more free 
buffers in the pool, but this was only verified for ixgbe 82599 cards, 
for igb the packets are not actually flushed until the tail circles back 
the whole length of the queue. I'm pretty much the only one (that I know 
of) that uses odp with 1G igb i350 cards and see this issue.

Can anyone explain whether I'm getting this right and there could be 
side effects to calling eth_igb_xmit_pkts with len 0?

Thank you,
/Ciprian