Hi Stephen, Thanks for the reply. Does that mean receive index skip is expected in case a packet spans across multiple segments ? I am seeing following behaviour :
We receive the packets in vmxnet3_recv_pkts function... this is done by checking gen bits (in a while loop). For each packet received, we increment next2proc in comp_ring and then fetch rxdIdx using next2proc value as follows : rcd = &rxq->comp_ring.base[rxq->comp_ring.next2proc].rcd; idx = rcd->rxdIdx; Now for the case when i am seeing packet drops, next2proc is getting incremented by 1 but rxdIdx gets incremented by 2. This is seen by printing the following in gdb : p rxq->comp_ring.next2proc p rxq->comp_ring.base[rxq->comp_ring.next2proc].rcd.rxdIdx $1094 = *262* $1095 = *6* //for next packet $1099 = *263* $1100 = *8* Is this too an expected behaviour ? In that case how we will receive the packet with rxdIdx = 7 ? thanks, gaurav On Mon, Sep 30, 2019 at 8:29 PM Stephen Hemminger < [email protected]> wrote: > On Mon, 30 Sep 2019 11:22:19 +0530 > Gaurav Bansal <[email protected]> wrote: > > > hi all, > > havn't heard back on this so far. Can anyone please let me know of the > > possible reasons for the NIC to skip some of the indexes of the > descriptor > > ring in the Rx path (as also shown by the vmxnet3 logs in my previous > mail) > > ? > > thanks, > > gaurav > > > > A packet can span multiple segments if your receive mbuf is too small to > fit > all the data. That would cause the receive data to create a chained mbuf. > > >
