From: Joe Damato <joe@dama.to>
To: Michael Chan <michael.chan@broadcom.com>
Cc: netdev@vger.kernel.org, Pavan Chebbi <pavan.chebbi@broadcom.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
edumazet@google.com, horms@kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net 2/2] bnxt_en: Pad short SW USO segments to BNXT_MIN_PKT_SIZE
Date: Fri, 9 Oct 2026 13:23:15 -0700 [thread overview]
Message-ID: <aslNM7TjcZ/17/MS@devvm20253.cco0.facebook.com> (raw)
In-Reply-To: <CACKFLi=0uuY36A+pnHVDqRYACfC5WVXx357cgD5BDMiTfW9sRA@mail.gmail.com>
On Fri, Oct 09, 2026 at 01:07:59PM -0700, Michael Chan wrote:
> On Fri, Oct 9, 2026 at 12:45 PM Joe Damato <joe@dama.to> wrote:
> >
> > On Fri, Oct 09, 2026 at 11:33:07AM -0700, Michael Chan wrote:
> > > Did you mean generic XDP turning around incoming packets with XDP_TX
> > > actions and transmitting them through the software stack? This path
> > > cannot generate USO packets, right?
> >
> > Hm, I'm probably missing something, but the case I'm describing is generic XDP
> > bouncing received packets back out with XDP_TX.
> >
> > I could be wrong (and if so I am happy to drop this if statement from the
> > code), but IIUC generic XDP runs from __netif_receive_skb_core() after
> > software GRO, so the packet it sees can be a GRO'd UDP packet with
> > SKB_GSO_UDP_L4 set (because maybe the socket had UDP_GRO set?).
> >
> > The generic XDP path seems to keep all of the gso fields. Later generic
> > XDP TX calls netdev_start_xmit without validate_xmit_skb being called
> > and so gso_size could potentially be some tiny value.
>
> I don't know. You may be right, but this is a highly unusual code
> path. Other features checked in bnxt_features_check() do not get
> rechecked again.
>
> If you decide to keep the check, please add a comment. Thanks.
OK, I'll submit a v2 with the following comment. Let me know if this OK
with you before I respin:
/* bnxt_features_check() makes the stack segment these, but paths
* that skip validate_xmit_skb() (e.g. generic XDP_TX of a GRO'd
* skb) can still get here. Padding every segment would need more
* BDs than bds_needed reserves below, so drop instead.
*/
if (unlikely(bnxt_sw_gso_pad_len(hdr_len, mss)))
goto drop;
Also, since I haven't seen this issue in production myself and according
to my math it is not possible to hit this with QUIC on ipv4, Jakub asked
me to submit this to net-next instead of net.
next prev parent reply other threads:[~2026-10-09 20:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 19:11 [PATCH net 0/2] bnxt_en: Fix SW USO padding Joe Damato
2026-10-08 19:11 ` [PATCH net 1/2] bnxt_en: Add helper to fill SW USO payload BDs Joe Damato
2026-10-08 19:11 ` [PATCH net 2/2] bnxt_en: Pad short SW USO segments to BNXT_MIN_PKT_SIZE Joe Damato
2026-10-09 5:26 ` Michael Chan
2026-10-09 17:33 ` Joe Damato
2026-10-09 18:33 ` Michael Chan
2026-10-09 19:45 ` Joe Damato
2026-10-09 20:07 ` Michael Chan
2026-10-09 20:23 ` Joe Damato [this message]
2026-10-09 20:28 ` Michael Chan
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=aslNM7TjcZ/17/MS@devvm20253.cco0.facebook.com \
--to=joe@dama.to \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=stable@vger.kernel.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 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.