From: Stephen Hemminger <stephen@networkplumber.org>
To: Alan Beadle <ab.beadle@gmail.com>
Cc: users@dpdk.org
Subject: Re: mbufs getting reused despite nonzero refcnt
Date: Sun, 10 Nov 2024 09:12:45 -0800 [thread overview]
Message-ID: <20241110091245.677a3983@hermes.local> (raw)
In-Reply-To: <CANTAOdyTaJCuMt8FccJOOkdu5kJ36Xt8=FwGoNOccPqin6W5fw@mail.gmail.com>
On Sun, 10 Nov 2024 11:23:29 -0500
Alan Beadle <ab.beadle@gmail.com> wrote:
> Hi everyone,
>
> I am using DPDK to send two-way traffic between a pair of machines. My
> application has local readers, remote acknowledgments, as well as
> automatic retries when a packet is lost. For these reasons I am using
> rte_mbuf_refcnt_update() to prevent the NIC from freeing the packet
> and recycling the mbuf before my local readers are done and the remote
> reader has acknowledged the message. I was advised to do this in an
> earlier thread on this mailing list.
>
> However, this does not seem to be working. After running my app for
> awhile and exchanging about 1000 messages in this way, my queue of
> unacknowledged mbufs is getting corrupted. The mbufs attached to my
> queue seem to contain data for newer messages than what is supposed to
> be in them, and in some cases contains a totally different type of
> packet (an acknack for instance). Obviously this results in retries of
> those messages failing to send the correct data and my application
> gets stuck.
>
> I have ensured that the refcount is not reaching 0. Each new mbuf
> immediately has the refcnt incremented by 1. I was concerned that
> retries might need the refcnt bumped again, but if I bump the refcount
> every time I resend a specific mbuf to the NIC, the refcounts just
> keep getting higher. So it looks like re-bumping it on a resend is not
> necessary.
>
> I have ruled out other possible explanations. The mbufs are being
> reused by rte_pktmbuf_alloc. I even tried playing with the EAL
> settings related to the number of mbuf descriptors and saw my changes
> directly correlate with how long it takes this problem to occur. How
> do I really prevent the driver from reusing packets that I still might
> need to resend?
>
> Thanks in advance,
> -Alan
Which driver, could be a driver bug.
Also, you should be able to trace mbuf functions, either with rte_trace
or by other facility.
next prev parent reply other threads:[~2024-11-10 17:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-10 16:23 Alan Beadle
2024-11-10 17:12 ` Stephen Hemminger [this message]
2024-11-10 17:31 ` Alan Beadle
2024-11-12 13:02 ` Alan Beadle
2024-11-14 16:14 ` Alan Beadle
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=20241110091245.677a3983@hermes.local \
--to=stephen@networkplumber.org \
--cc=ab.beadle@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).