Re: [dpdk-users] packet drops with missing rxdIdx count in vmxnet3

[Gaurav Bansal <zeebee48@gmail.com>]

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 <
stephen@networkplumber.org> wrote:

> On Mon, 30 Sep 2019 11:22:19 +0530
> Gaurav Bansal <zeebee48@gmail.com> 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.
>
>
>