From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
andrew+netdev@lunn.ch, horms@kernel.org, jv@jvosburgh.net,
hawk@kernel.org, sdf@fomichev.me, emil@etsalapatis.com,
liuhangbin@gmail.com, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org, willemdebruijn.kernel@gmail.com,
aleksander.lobakin@intel.com, Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next 0/5] net: fix a couple of problems with XDP and bonding
Date: Mon, 28 Sep 2026 15:36:43 -0700 [thread overview]
Message-ID: <20260928223648.2739371-1-kuba@kernel.org> (raw)
I started looking at untangling XDP vs HW-GRO story because of mlx5.
mlx5 requires HW-GRO for HDS/memory providers. But generic XDP clears
HW-GRO enablement completely. This is annoying in NIPA but also,
from past experience with XDP changing ring geometry and IRQ mapping,
it will also be annoying in production.
My plan / hope is to make generic XDP attachment leave HW-GRO in wanted
features, that way it comes back after XDP is removed, making NIPA happy.
This also simplifies the drivers slightly, as they no longer have to
check XDP vs HW-GRO locally.
This is the most important part, I think - I would like to make
the claim that HW-GRO and XDP are incompatible (today). Most drivers
seem to agree, but IDPF allows XDP and HW-GRO to coexist. XDP can't
carry the GRO/GSO state so changing the packet or trying to send it
out would probably end badly. We should explicitly clear HW-GRO when
XDP is attached in the core, until we have an understanding of how
they would work together, and appropriate tests.
Please comment if you have opinion on the HW-GRO+XDP in general,
that said, this series is just prep around bonding. What I described
above will come next.
This series tries to shore up the gaps in XDP propagation.
bonding bypasses the XDP program accounting in net_device so all
the checks on control path trying to avoid enabling features
incompatible with XDP are moot (e.g. we can have XDP+memory providers).
First patch fixes the accounting (next 3 patches add tests).
Last patch makes us drop GSO packets if they reach XDP. I can't come
up with a clean way of stopping GRO from working on lower when upper
has generic XDP, so let's just drop the packets. I don't think
generic XDP is worth the effort, users can disable GRO themselves
if they really care.
All the issues here were discovered while working another series,
but they were reproduced and tested with the selftests included.
Jakub Kicinski (5):
net: record XDP programs propagated to lower devices
netdevsim: add ndo_xdp_xmit
selftests: drv-net: check tcp-data-split against an already attached
XDP
selftests/bpf: check XDP attach on a nested bond slave
net: drop GSO skbs instead of handing them to XDP
include/linux/netdevice.h | 7 ++
include/net/xdp.h | 16 +++
drivers/net/bonding/bond_main.c | 4 +-
drivers/net/netdevsim/netdev.c | 20 ++++
drivers/net/veth.c | 3 +
net/core/dev.c | 105 +++++++++++++-----
.../selftests/bpf/prog_tests/xdp_bonding.c | 18 ++-
tools/testing/selftests/drivers/net/config | 1 +
tools/testing/selftests/drivers/net/hds.py | 65 +++++++++++
9 files changed, 206 insertions(+), 33 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-28 22:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 22:36 Jakub Kicinski [this message]
2026-09-28 22:36 ` [PATCH net-next 1/5] net: record XDP programs propagated to lower devices Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 2/5] netdevsim: add ndo_xdp_xmit Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 3/5] selftests: drv-net: check tcp-data-split against an already attached XDP Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 4/5] selftests/bpf: check XDP attach on a nested bond slave Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 5/5] net: drop GSO skbs instead of handing them to XDP Jakub Kicinski
2026-09-29 23:33 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
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=20260928223648.2739371-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=emil@etsalapatis.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=linux-kselftest@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=willemdebruijn.kernel@gmail.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