From: Jakub Kicinski <kuba@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: "Nikhil P. Rao" <nikhil.rao@amd.com>, <netdev@vger.kernel.org>,
<magnus.karlsson@intel.com>, <sdf@fomichev.me>,
<davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
<horms@kernel.org>, <kerneljasonxing@gmail.com>
Subject: Re: [PATCH net v4 2/2] xsk: Fix zero-copy AF_XDP fragment drop
Date: Fri, 20 Feb 2026 12:38:13 -0800 [thread overview]
Message-ID: <20260220123813.61780c4f@kernel.org> (raw)
In-Reply-To: <aZhVdcTDceAlhLvV@boxer>
On Fri, 20 Feb 2026 13:37:09 +0100 Maciej Fijalkowski wrote:
> > Personal preference perhaps but removing error checking always
> > gives me pause. Maybe:
> >
> > bool frag_fail;
> >
> > frag_fail = __xsk_rcv_zc(xs, xskb, len, contd);
> > list_for_each...
> > ...
> > frag_fail |= __xsk_rcv_zc(xs, xskb, len, contd);
> > DEBUG_NET_WARN_ON_ONCE(frag_fail);
>
> error checking can be actually skipped as xskq_prod_nb_free() peeked into
> xsk rx queue and told us there is enough space for descriptor production.
Understood. I was wondering whether the assert / DEBUG_NET.. may still
be worth keeping but up to you.
> Nikhil, I also see you routed the set to 'net' tree, previously xsk core
> was handled via bpf/bpf-next.
Dunno... We had mixed results, I think net / net-next is fine for stuff
that's purely packet movement. There is no BPF dependency here..
Unless you have a reason! I'm not feeling strongly. Just the stuff we
were fixing recently made me wonder if this code is getting sufficient
networking eyes..
prev parent reply other threads:[~2026-02-20 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 21:08 [PATCH net v4 0/2] xsk: Fixes for AF_XDP fragment handling Nikhil P. Rao
2026-02-17 21:08 ` [PATCH net v4 1/2] xsk: Fix fragment node deletion to prevent buffer leak Nikhil P. Rao
2026-02-17 21:08 ` [PATCH net v4 2/2] xsk: Fix zero-copy AF_XDP fragment drop Nikhil P. Rao
2026-02-19 22:55 ` Jakub Kicinski
2026-02-20 12:37 ` Maciej Fijalkowski
2026-02-20 20:38 ` Jakub Kicinski [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=20260220123813.61780c4f@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kerneljasonxing@gmail.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nikhil.rao@amd.com \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.