rte_eth_rx bug? duplicate message bufs

rte_eth_rx bug? duplicate message bufs

[Lavanya Jose]

Hi,

I was wondering if anyone on this list has come across this problem of
rte_eth_rx_burst returning the same mbuf contents multiple times especially
during congestion. I notice this problem after some number of calls to
rte_eth_rx_burst when I set the nb_pkts argument to anything more than 5. I
did confirm that the contents (random payloads) in the duplicate packets
are identical.

I looked at the corresponding ixgbe driver code that gets packets from the
rx ring.
<https://github.com/emmericp/dpdk/blob/e5b112e4c7a4d63f3131294e9611e4a892b75008/drivers/net/ixgbe/ixgbe_rxtx.c#L1595>
It looks like the driver doesn't drop packets if an mbuf allocation fails.
I'm not sure if this is the root cause of the bug I'm seeing?

I'm also curious about whether I need to set rx_descs and tx_descs to 40
when I'm setting up the Intel 82599 device? The datasheet says there's 40
descriptors per TX queue though default values I've seen in code are much
larger..

Thanks,
Lavanya

Re: rte_eth_rx bug? duplicate message bufs

[Yeddula, Avinash]

Hi All,
I do have a similar issue, any response to the below email might help me as well.

Thanks
-Avinash

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Lavanya Jose
Sent: Monday, August 08, 2016 11:44 AM
To: users@dpdk.org; dev@dpdk.org
Subject: [dpdk-dev] rte_eth_rx bug? duplicate message bufs

Hi,

I was wondering if anyone on this list has come across this problem of rte_eth_rx_burst returning the same mbuf contents multiple times especially during congestion. I notice this problem after some number of calls to rte_eth_rx_burst when I set the nb_pkts argument to anything more than 5. I did confirm that the contents (random payloads) in the duplicate packets are identical.

I looked at the corresponding ixgbe driver code that gets packets from the rx ring.
<https://github.com/emmericp/dpdk/blob/e5b112e4c7a4d63f3131294e9611e4a892b75008/drivers/net/ixgbe/ixgbe_rxtx.c#L1595>
It looks like the driver doesn't drop packets if an mbuf allocation fails.
I'm not sure if this is the root cause of the bug I'm seeing?

I'm also curious about whether I need to set rx_descs and tx_descs to 40 when I'm setting up the Intel 82599 device? The datasheet says there's 40 descriptors per TX queue though default values I've seen in code are much larger..

Thanks,
Lavanya

Re: rte_eth_rx bug? duplicate message bufs

[Lavanya Jose]

Hi Avinash,

For me it turned out to be a bug with duplicate detection code rather than
with DPDK. The sequence numbers were wrapping over and I didn't have enough
random bits for the payload either.

- Lavanya

On Thu, Aug 11, 2016 at 4:53 PM Yeddula, Avinash <ayeddula@ciena.com> wrote:

> Hi All,
> I do have a similar issue, any response to the below email might help me
> as well.
>
> Thanks
> -Avinash
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Lavanya Jose
> Sent: Monday, August 08, 2016 11:44 AM
> To: users@dpdk.org; dev@dpdk.org
> Subject: [dpdk-dev] rte_eth_rx bug? duplicate message bufs
>
> Hi,
>
> I was wondering if anyone on this list has come across this problem of
> rte_eth_rx_burst returning the same mbuf contents multiple times especially
> during congestion. I notice this problem after some number of calls to
> rte_eth_rx_burst when I set the nb_pkts argument to anything more than 5. I
> did confirm that the contents (random payloads) in the duplicate packets
> are identical.
>
> I looked at the corresponding ixgbe driver code that gets packets from the
> rx ring.
> <
> https://github.com/emmericp/dpdk/blob/e5b112e4c7a4d63f3131294e9611e4a892b75008/drivers/net/ixgbe/ixgbe_rxtx.c#L1595
> >
> It looks like the driver doesn't drop packets if an mbuf allocation fails.
> I'm not sure if this is the root cause of the bug I'm seeing?
>
> I'm also curious about whether I need to set rx_descs and tx_descs to 40
> when I'm setting up the Intel 82599 device? The datasheet says there's 40
> descriptors per TX queue though default values I've seen in code are much
> larger..
>
> Thanks,
> Lavanya
>