DPDK usage discussions
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: David Aldrich <david.aldrich.ntml@gmail.com>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] A question about l2fwd
Date: Wed, 24 Jun 2020 11:54:21 +0000	[thread overview]
Message-ID: <BYAPR11MB3143EDB953E9DBABA5ED2BB4D7950@BYAPR11MB3143.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAJK_ieh4dPQGgW2E_U4iGOGOYnK6wM+5bWWUscjSAhMddcNuvA@mail.gmail.com>

> -----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

      reply	other threads:[~2020-06-24 11:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 11:28 David Aldrich
2020-06-24 11:54 ` Van Haaren, Harry [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR11MB3143EDB953E9DBABA5ED2BB4D7950@BYAPR11MB3143.namprd11.prod.outlook.com \
    --to=harry.van.haaren@intel.com \
    --cc=david.aldrich.ntml@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).