From: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev-bot+sashiko@kernel.org, maxime.chevallier@bootlin.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
kuba@kernel.org, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com, ast@kernel.org,
daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com,
sdf@fomichev.me, boon.leong.ong@intel.com,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
bpf@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] net: stmmac: disable TX checksum offload for jumbo frames on bugged cores
Date: Tue, 20 Oct 2026 15:17:51 +0200 [thread overview]
Message-ID: <atdp_0QJfjR_H3U-@lore-desk> (raw)
In-Reply-To: <de6dc65e-04bf-40b2-b5e6-d7035d2f9b7c@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
> On 10/13/26 17:33, Lorenzo Bianconi wrote:
> > > Thank you for your contribution! Sashiko AI review found more severe
> > > issue(s) in other patches of this series. This mail is only an FYI, in case
> > > you want to address the nit picks below when you respin.
> > >
> > > Low priority / nit picks for your consideration:
> > >
> > > - [Low] The commit message's premise doesn't match the tree.
> > >
> > > Pre-existing issues:
> > > - [Medium] This problem wasn't introduced by this patch, but
> > > stmmac_xdp_xmit_xdpf() never looks at priv->plat->tx_coe when deciding…
> > >
> > > --
> > >
> > > net: stmmac: disable TX checksum offload for jumbo frames on bugged cores
> > >
> > > This patch turns off TX checksum insertion in stmmac_xdp_xmit_xdpf() for
> > > frames longer than ETH_FRAME_LEN on bugged_jumbo cores. It is meant to
> > > match the stmmac_fix_features() workaround that the skb path already uses.
> > >
> > > > The XDP TX
> > > > path bypasses that workaround, so once XDP is allowed at MTU >
> > > > ETH_DATA_LEN, jumbo frames sent via XDP_TX or redirected into the
> > > > device would leave the interface with a full checksum insertion enabled
> > > > on those cores - exactly what the workaround is meant to avoid.
> > >
> > > [Severity: Low]
> > > Can this scenario happen in the current tree? XDP still can't be used with
> > > a jumbo MTU. stmmac_xdp_set_prog() refuses to attach a program when the MTU
> > > is above ETH_DATA_LEN:
> >
> > This is actually a preliminary fix needed to remove the MTU limitation when the
> > device is running in XDP mode.
> The point is that this patch does not address any issues, no it should not
> include a fixes tag. I'll drop it while applying the series.
ack, thx Paolo for fixing it.
Regards,
Lorenzo
>
> Also a more explicative cover letter would have helped.
>
> No need to repost.
>
> Thanks,
>
> Paolo
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-10-20 13:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 15:24 [PATCH net-next 0/2] stmmac: some XDP fixes in XDP_TX path Lorenzo Bianconi
2026-10-12 15:24 ` [PATCH net-next 1/2] net: stmmac: fix XDP TX DMA address for compound RX pages Lorenzo Bianconi
2026-10-12 19:43 ` Daniel Machon
2026-10-12 20:47 ` Lorenzo Bianconi
2026-10-13 7:54 ` Daniel Machon
2026-10-13 15:27 ` netdev-bot+sashiko
2026-10-13 15:40 ` Lorenzo Bianconi
2026-10-16 14:13 ` Maxime Chevallier
2026-10-12 15:24 ` [PATCH net-next 2/2] net: stmmac: disable TX checksum offload for jumbo frames on bugged cores Lorenzo Bianconi
2026-10-13 15:27 ` netdev-bot+sashiko
2026-10-13 15:33 ` Lorenzo Bianconi
2026-10-19 13:40 ` Paolo Abeni
2026-10-20 13:17 ` Lorenzo Bianconi [this message]
2026-10-16 14:18 ` Maxime Chevallier
2026-10-20 0:57 ` Jisheng Zhang
2026-10-20 3:08 ` Jisheng Zhang
2026-10-20 12:28 ` Andrew Lunn
2026-10-12 15:30 ` [PATCH net-next 0/2] stmmac: some XDP fixes in XDP_TX path netdev-bot+sinfo
2026-10-12 15:52 ` Lorenzo Bianconi
2026-10-19 13:50 ` patchwork-bot+netdevbpf
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=atdp_0QJfjR_H3U-@lore-desk \
--to=lorenzo.bianconi@oss.qualcomm.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=boon.leong.ong@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--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.