[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dpdk-users
Subject:    Re: [dpdk-users] A question about l2fwd
From:       "Van Haaren, Harry" <harry.van.haaren () intel ! com>
Date:       2020-06-24 11:54:21
Message-ID: BYAPR11MB3143EDB953E9DBABA5ED2BB4D7950 () BYAPR11MB3143 ! namprd11 ! prod ! outlook ! com
[Download RAW message or body]

> -----Original Message-----
> From: users <users-bounces@dpdk.org> On Behalf Of David Aldrich
> Sent: Wednesday, June 24, 2020 12:29 PM
> To: users@dpdk.org
> Subject: [dpdk-users] A question about l2fwd
> 
> Hi,

Hi David!

> I have a question about the l2fwd example, which concerns a basic question
> about how dpdk works.
> 
> The main processing loop in l2fwd is *l2fwd_main_loop()* which calls
> *rte_eth_rx_burst()* to retrieve packets from the rx_queue.
> 
> My question is: what processing loop is responsible for transferring
> packets from the ethernet device to the rx_queue?

The NIC hardware has a DMA engine, and writes to the descriptor ring
when a packet arrives. It also DMAs the packet data to a memory location
that was provided by SW in advance.

The SW rte_eth_rx_burst() function polls this descriptor ring, and checks if
new packets are available. There is often a single bit "Descriptor Done", or DD
for short, that indicates a new packet has been written by the NIC.


> I ask this because we have written our own application based on l2fwd and
> no packets are being returned by our app's call to
> *rte_eth_rx_burst(). *However,
> packets are returned in the case of l2fwd. I'm trying to identify the
> difference between the non-working and working code.

Check that you're calling with a big enough burst size (4 or greater),
as some of the SIMD/vector PMD routines do not like small burst sizes.

If there's still an error, ensure that the mempool hasn't been depleted.
Often caused by leaking packet mbufs, due to not calling rte_pktmbuf_free().

Try adding some stats to your application to count eg: rx_pkts, rte_pktmbuf_free() calls.
Sometimes comparing the two shows some packets being leaked.

> Best regards
> David

Hope that helps! -Harry

[prev in list] [next in list] [prev in thread] [next in thread]