From: Chris Arges <carges@cloudflare.com>
To: Dragos Tatulea <dtatulea@nvidia.com>
Cc: Jesse Brandeburg <jbrandeburg@cloudflare.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
kernel-team <kernel-team@cloudflare.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
tariqt@nvidia.com, saeedm@nvidia.com,
Leon Romanovsky <leon@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Simon Horman <horms@kernel.org>,
Andrew Rzeznik <arzeznik@cloudflare.com>,
Yan Zhai <yan@cloudflare.com>
Subject: Re: [BUG] mlx5_core memory management issue
Date: Wed, 13 Aug 2025 13:53:48 -0500 [thread overview]
Message-ID: <aJzfPFCTlc35b2Bp@861G6M3> (raw)
In-Reply-To: <aJuxY9oTtxSn4qZP@861G6M3>
On 2025-08-12 16:25:58, Chris Arges wrote:
> On 2025-08-12 20:19:30, Dragos Tatulea wrote:
> > On Tue, Aug 12, 2025 at 11:55:39AM -0700, Jesse Brandeburg wrote:
> > > On 8/12/25 8:44 AM, 'Dragos Tatulea' via kernel-team wrote:
> > >
> > > > diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> > > > index 482d284a1553..484216c7454d 100644
> > > > --- a/kernel/bpf/devmap.c
> > > > +++ b/kernel/bpf/devmap.c
> > > > @@ -408,8 +408,10 @@ static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags)
> > > > /* If not all frames have been transmitted, it is our
> > > > * responsibility to free them
> > > > */
> > > > + xdp_set_return_frame_no_direct();
> > > > for (i = sent; unlikely(i < to_send); i++)
> > > > xdp_return_frame_rx_napi(bq->q[i]);
> > > > + xdp_clear_return_frame_no_direct();
> > >
> > > Why can't this instead just be xdp_return_frame(bq->q[i]); with no
> > > "no_direct" fussing?
> > >
> > > Wouldn't this be the safest way for this function to call frame completion?
> > > It seems like presuming the calling context is napi is wrong?
> > >
> > It would be better indeed. Thanks for removing my horse glasses!
> >
> > Once Chris verifies that this works for him I can prepare a fix patch.
> >
> Working on that now, I'm testing a kernel with the following change:
>
> ---
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index 3aa002a47..ef86d9e06 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -409,7 +409,7 @@ static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags)
> * responsibility to free them
> */
> for (i = sent; unlikely(i < to_send); i++)
> - xdp_return_frame_rx_napi(bq->q[i]);
> + xdp_return_frame(bq->q[i]);
>
> out:
> bq->count = 0;
This patch resolves the issue I was seeing and I am no longer able to
reproduce the issue. I tested for about 2 hours, when the reproducer usually
takes about 1-2 minutes.
--chris
next prev parent reply other threads:[~2025-08-13 18:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 15:49 [BUG] mlx5_core memory management issue Chris Arges
2025-07-04 12:37 ` Dragos Tatulea
2025-07-04 20:14 ` Dragos Tatulea
2025-07-07 22:07 ` Chris Arges
2025-07-23 18:48 ` Chris Arges
2025-07-24 17:01 ` Dragos Tatulea
2025-08-07 16:45 ` Chris Arges
2025-08-11 8:37 ` Dragos Tatulea
2025-08-12 15:44 ` Dragos Tatulea
2025-08-12 18:55 ` Jesse Brandeburg
2025-08-12 20:19 ` Dragos Tatulea
2025-08-12 21:25 ` Chris Arges
2025-08-13 18:53 ` Chris Arges [this message]
2025-08-13 19:26 ` Dragos Tatulea
2025-08-13 20:24 ` Dragos Tatulea
2025-08-14 11:26 ` Jesper Dangaard Brouer
2025-08-14 14:42 ` Dragos Tatulea
2025-08-14 15:58 ` Jesper Dangaard Brouer
2025-08-14 16:45 ` Dragos Tatulea
2025-08-15 14:59 ` Jakub Kicinski
2025-08-15 16:02 ` Jesper Dangaard Brouer
2025-08-15 16:36 ` Jakub Kicinski
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=aJzfPFCTlc35b2Bp@861G6M3 \
--to=carges@cloudflare.com \
--cc=andrew+netdev@lunn.ch \
--cc=arzeznik@cloudflare.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jbrandeburg@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=yan@cloudflare.com \
/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).