DPDK usage discussions
 help / color / mirror / Atom feed
From: "Lombardo, Ed" <Ed.Lombardo@netscout.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Ivan Malov <ivan.malov@arknetworks.am>, users <users@dpdk.org>
Subject: RE: dpdk Tx falling short
Date: Sun, 6 Jul 2025 17:44:49 +0000	[thread overview]
Message-ID: <CH3PR01MB8470EAA7AB3F584F1A8BCB038F4CA@CH3PR01MB8470.prod.exchangelabs.com> (raw)
In-Reply-To: <20250706090232.635bd36e@hermes.local>

Hi Stephen,
If using dpdk rings comes with this penalty then what should I use, is there an alterative to rings.  We do not want to use shared memory and do buffer copies?

Thanks,
Ed

-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Sunday, July 6, 2025 12:03 PM
To: Lombardo, Ed <Ed.Lombardo@netscout.com>
Cc: Ivan Malov <ivan.malov@arknetworks.am>; users <users@dpdk.org>
Subject: Re: dpdk Tx falling short

External Email: This message originated outside of NETSCOUT. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Sun, 6 Jul 2025 00:03:16 +0000
"Lombardo, Ed" <Ed.Lombardo@netscout.com> wrote:

> Hi Stephen,
> Here are comments to the list of obvious causes of cache misses you mentiond.
> 
> Obvious cache misses.
>  - passing packets to worker with ring - we use lots of rings to pass mbuf pointers.  If I skip the rte_eth_tx_burst() and just free mbuf bulk, the tx ring does not fill up.
>  - using spinlocks (cost 16ns)  - The driver does not use spinlocks, other than what dpdk uses.
>  - fetching TSC  - We don't do this, we let Rx offload timestamp packets.
>  - syscalls?  - No syscalls are done in our driver fast path.
> 
> You mention "passing packets to worker with ring", do you mean using rings to pass mbuf pointers causes cache misses and should be avoided?

Rings do cause data to be modified by one core and examined by another so they are a cache miss.


  reply	other threads:[~2025-07-06 17:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03 20:14 Lombardo, Ed
2025-07-03 21:49 ` Stephen Hemminger
2025-07-04  5:58   ` Rajesh Kumar
2025-07-04 11:44 ` Ivan Malov
2025-07-04 14:49   ` Stephen Hemminger
2025-07-05 17:36     ` Lombardo, Ed
2025-07-05 19:02       ` Stephen Hemminger
2025-07-05 19:08       ` Stephen Hemminger
2025-07-06  0:03         ` Lombardo, Ed
2025-07-06 16:02           ` Stephen Hemminger
2025-07-06 17:44             ` Lombardo, Ed [this message]
2025-07-07  3:30               ` Stephen Hemminger
2025-07-05 17:33   ` Lombardo, Ed

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=CH3PR01MB8470EAA7AB3F584F1A8BCB038F4CA@CH3PR01MB8470.prod.exchangelabs.com \
    --to=ed.lombardo@netscout.com \
    --cc=ivan.malov@arknetworks.am \
    --cc=stephen@networkplumber.org \
    --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).