From: Stanislav Fomichev <sdf.kernel@gmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch, edumazet@kernel.org,
horms@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
rdunlap@infradead.org, michael.chan@broadcom.com,
pavan.chebbi@broadcom.com, saeedm@nvidia.com, tariqt@nvidia.com,
mbloch@nvidia.com, alexanderduyck@fb.com, kernel-team@meta.com,
sdf@fomichev.me, dimitri.daskalakis1@gmail.com,
almasrymina@google.com, dtatulea@nvidia.com,
bobbyeshleman@meta.com, asml.silence@gmail.com,
daniel@iogearbox.net, razor@blackwall.org, leitao@debian.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-kselftest@vger.kernel.org,
leon@kernel.org
Subject: [PATCH net-next v3 0/9] net: devmem: size TX net_iovs from the dmabuf layout
Date: Thu, 5 Nov 2026 14:20:49 -0800 [thread overview]
Message-ID: <20261105222058.944293-1-sdf@fomichev.me> (raw)
TX bindings use PAGE_SIZE net_iovs, so a frag covers at most a page.
A 64KB skb needs 16 frags, and MAX_SKB_FRAGS caps devmem skbs at about
68KB, which makes BIG TCP ineffective for devmem TX.
This series picks the TX net_iov size from the dmabuf sg table instead:
the largest power of 2, up to 2MB, which aligns every DMA segment. With
a 2MB hugepage-backed udmabuf a BIG TCP skb takes a few frags. There's
no UAPI change since TX addresses are dmabuf offsets.
TCP still bounds skbs by size_goal, so frags get larger, skbs don't.
Devmem TX frags are capped by a new per-device limit, PAGE_SIZE by
default, so drivers opt in to larger frags:
- mlx5: no limit, 32-bit length per data segment
- bnxt, fbnic: 32KB, 16-bit TX descriptor length
- gve keeps PAGE_SIZE frags
Tested on two mlx5 400Gb/s hosts with kperf (udmabuf, 32KB RX
net_iovs, 2MB hugepage-backed TX buffer), series backported to a 7.1
kernel on the sender only. 1 flow, MTU 4200, receiver tcp_rmem capped
at 16MB so it doesn't drop, median of 5 x 60s runs:
before after
frags per skb (sender) 16-17 1-2
throughput (Gb/s) 208.6 211.2
sender sendmsg CPU (sys) 40.8% 19.5% (-52%)
The receiver's CPU is the bottleneck, so the gain is CPU, not
throughput. More of the transmit runs from the ACK path, so the
sender's softirq grows (52% -> 59%), but sys + sirq still drops by 16%.
kperf output (sender side) of runs near the median, before:
client: == Source <sender>
client: Tx213.826 Gbps (1603901849600 bytes in 60007723 usec)
client: Rx 0.000 Gbps (0 bytes in 60007723 usec)
client: TCP retrans reord rtt rttvar d_ce snd_wnd cwnd
client: 0 0 633 2 0 15556608 7657
client: net CPU 49: usr: 0.01% sys: 0.10% idle:44.13% iow: 0.00% irq: 3.21% sirq:52.53%
client: app CPU 50: usr: 0.05% sys:41.55% idle:53.88% iow: 0.00% irq: 1.40% sirq: 3.10%
after:
client: == Source <sender>
client: Tx211.242 Gbps (1584440279040 bytes in 60004741 usec)
client: Rx 0.000 Gbps (0 bytes in 60004741 usec)
client: TCP retrans reord rtt rttvar d_ce snd_wnd cwnd
client: 0 0 556 3 0 15499264 7650
client: net CPU 13: usr: 0.01% sys: 0.08% idle:37.75% iow: 0.00% irq: 3.87% sirq:58.26%
client: app CPU 14: usr: 0.06% sys:19.48% idle:77.23% iow: 0.00% irq: 1.19% sirq: 2.02%
The bnxt patches (1 and 5) were tested on two 50Gb/s bnxt hosts with
CONFIG_MAX_SKB_FRAGS=45 (with 17 the check in patch 1 compiles out).
kperf devmem TX from a 2MB hugepage-backed udmabuf runs at line rate
(46.4Gb/s, payload validated) with 2-3 frags per skb, none above 32KB.
ncdevmem sending 1KB chunks builds skbs with up to 45 frags, the stack
segments them and the data arrives intact. The fbnic patch is
build-tested only.
Patches:
- 1: bnxt: segment GSO skbs with too many frags in the stack
- 2-3: devmem TX prep (truesize, niov_shift in the TX lookup)
- 4-7: per-device netmem TX frag size limit, PAGE_SIZE by default,
opt-ins for bnxt, fbnic and mlx5
- 8: pick the TX net_iov size from the sg table
- 9: selftest for TX from a hugepage-backed dmabuf
v3:
- default the netmem TX frag size limit to PAGE_SIZE, opt in bnxt,
fbnic and mlx5 (Mina)
v2: https://lore.kernel.org/netdev/20261103235152.1904727-1-sdf@fomichev.me/
- reword the TX truesize commit message (Mina)
- explain why the TX net_iov size ignores the device limit (Mina)
- use 1 flow results in the cover letter (Mina)
v1: https://lore.kernel.org/netdev/20261102191438.1059771-1-sdf@fomichev.me/
Stanislav Fomichev (9):
bnxt_en: let the stack segment GSO skbs with too many frags
net: devmem: charge the frag length to TX skb truesize
net: devmem: use niov_shift in net_devmem_get_niov_at()
net: devmem: add a per-device netmem TX frag size limit
bnxt_en: set the netmem TX frag size limit to 32KB
eth: fbnic: set the netmem TX frag size limit to 32KB
net/mlx5e: lift the netmem TX frag size limit
net: devmem: size TX net_iovs from the dmabuf sg table
selftests: drv-net: devmem: TX from a hugepage-backed dmabuf
.../networking/net_cachelines/net_device.rst | 1 +
Documentation/networking/netmem.rst | 7 +++
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +++
.../net/ethernet/mellanox/mlx5/core/en_main.c | 1 +
.../net/ethernet/meta/fbnic/fbnic_netdev.c | 1 +
include/linux/netdevice.h | 2 +
net/core/datagram.c | 3 +-
net/core/dev.c | 1 +
net/core/devmem.c | 37 +++++++++++++---
net/core/devmem.h | 1 +
net/core/netdev-genl.c | 2 +-
.../selftests/drivers/net/hw/devmem.py | 10 ++++-
.../selftests/drivers/net/hw/devmem_lib.py | 43 +++++++++++++++++--
.../selftests/drivers/net/hw/ncdevmem.c | 8 +++-
.../selftests/drivers/net/hw/nk_devmem.py | 11 ++++-
15 files changed, 118 insertions(+), 16 deletions(-)
--
2.53.0-Meta
next reply other threads:[~2026-11-05 22:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 22:20 Stanislav Fomichev [this message]
2026-11-05 22:20 ` [PATCH net-next v3 1/9] bnxt_en: let the stack segment GSO skbs with too many frags Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 2/9] net: devmem: charge the frag length to TX skb truesize Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 3/9] net: devmem: use niov_shift in net_devmem_get_niov_at() Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 4/9] net: devmem: add a per-device netmem TX frag size limit Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 5/9] bnxt_en: set the netmem TX frag size limit to 32KB Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 6/9] eth: fbnic: " Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 7/9] net/mlx5e: lift the netmem TX frag size limit Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 8/9] net: devmem: size TX net_iovs from the dmabuf sg table Stanislav Fomichev
2026-11-05 22:20 ` [PATCH net-next v3 9/9] selftests: drv-net: devmem: TX from a hugepage-backed dmabuf Stanislav Fomichev
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=20261105222058.944293-1-sdf@fomichev.me \
--to=sdf.kernel@gmail.com \
--cc=alexanderduyck@fb.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=asml.silence@gmail.com \
--cc=bobbyeshleman@meta.com \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dimitri.daskalakis1@gmail.com \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=razor@blackwall.org \
--cc=rdunlap@infradead.org \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=skhan@linuxfoundation.org \
--cc=tariqt@nvidia.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
all inboxes | Powered by JetHome®