[dpdk-users] Wrong Data In Buffer After Upgrade To 17.02.1

[dpdk-users] Wrong Data In Buffer After Upgrade To 17.02.1

[Cliff Burdick]

Hi, I upgraded from 2.2.0 to 17.02.1 using the i40e driver, and I'm seeing
very weird behavior that's easily reproducible. My receiving thread/lcore
calls rte_eth_rx_burst(), changes the endianess on some of the packet
headers, and puts the pktmbuf onto a ring for the next eal thread to
process and eventually free. After upgrading, I'm seeing that
when rte_eth_rx_burst starts reusing buffers from the mempool, it's
returning buffers that don't have the new packet's data, but rather the old
data where I had already changed the endianess on some of the headers. I
removed the ring part, and even doing:

1) rte_eth_rx_burst
2) Change endianness
3) free pktmbuf

all within the same thread causes this issue to happen too. I've looked
through the changelog and don't see anything obvious that would be causing
this. Has anyone seen this happen? Thanks

Re: [dpdk-users] Wrong Data In Buffer After Upgrade To 17.02.1

[Cliff Burdick]

Hi, after debugging this more, it seems like vector PMD mode for the i40e
driver in 17.02.1 is what's broken. If I disable that option, my code works
fine. Does anyone know if this is a bug, or possibly just an issue in the
way I'm using it? The feature was turned on by default after 2.2.0.

On Wed, Jun 21, 2017 at 8:42 AM, Cliff Burdick <shaklee3@gmail.com> wrote:

> Hi, I upgraded from 2.2.0 to 17.02.1 using the i40e driver, and I'm seeing
> very weird behavior that's easily reproducible. My receiving thread/lcore
> calls rte_eth_rx_burst(), changes the endianess on some of the packet
> headers, and puts the pktmbuf onto a ring for the next eal thread to
> process and eventually free. After upgrading, I'm seeing that
> when rte_eth_rx_burst starts reusing buffers from the mempool, it's
> returning buffers that don't have the new packet's data, but rather the old
> data where I had already changed the endianess on some of the headers. I
> removed the ring part, and even doing:
>
> 1) rte_eth_rx_burst
> 2) Change endianness
> 3) free pktmbuf
>
> all within the same thread causes this issue to happen too. I've looked
> through the changelog and don't see anything obvious that would be causing
> this. Has anyone seen this happen? Thanks
>