DPDK usage discussions
 help / color / mirror / Atom feed
From: Alan Beadle <ab.beadle@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: users@dpdk.org
Subject: Re: Force driver to free sent buffers?
Date: Thu, 10 Oct 2024 11:17:33 -0400	[thread overview]
Message-ID: <CANTAOdzA2LtHSKZ9v1Q1brHmmKBgGL6d4qgitOa9=nTk=5OT-Q@mail.gmail.com> (raw)
In-Reply-To: <CANTAOdyO+y9GSrRFK9jj_ELTru1QMakW9bBV1Wb8wuRYg2XfqA@mail.gmail.com>

On Thu, Oct 10, 2024 at 10:12 AM Alan Beadle <ab.beadle@gmail.com> wrote:
>
> On Sun, Oct 6, 2024 at 6:18 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > Drivers are free to hold onto transmitted mbuf's indefinitely.
> > Since DPDK does not use interrupts for normal Tx, the driver has to defer
> > doing cleaning up either on next Tx or sometimes Rx. There is a Tx threshold
> > that may impact some drivers, but not all.
>
> Stephen,
>
> How would I attempt to set this threshold to see if it impacts the
> driver that I am using? I cannot find any EAL parameters that seem to
> correspond to this.
>
> Having to re-allocate a new mbuf every time will hurt performance,
> especially since most of the packet header values will not be changing
> across packets but will need to be reinitialized in every newly
> allocated mbuf. I had really hoped to recycle a set of <100 or so
> mbufs.


(Stephen, sorry for the double email, forgot to reply-all).

I believe I have found a solution. I'll have to investigate the impact
on performance later but advice/analysis is appreciated. I initialized
the pool with a limit of 128 tx descriptors and set the tx ring buffer
size to match. Once the ring is full, the NIC seems to free things as
it goes, resulting in having no sent-but-unfreed mbufs most of the
time.

Please let me know if there's any major issue with this approach and
if there's anything else I can do. At least this behaves in a way that
I can design my app like I planned and I'm hoping it results in
non-bursty latencies and good performance.

-Alan

  reply	other threads:[~2024-10-10 15:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-06 16:38 Alan Beadle
2024-10-06 22:18 ` Stephen Hemminger
2024-10-10 14:12   ` Alan Beadle
2024-10-10 15:17     ` Alan Beadle [this message]
2024-10-07  6:52 ` David Marchand

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='CANTAOdzA2LtHSKZ9v1Q1brHmmKBgGL6d4qgitOa9=nTk=5OT-Q@mail.gmail.com' \
    --to=ab.beadle@gmail.com \
    --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).