From: Sandeep Haemoon <sandeeph@loljews.com>
To: netdev@vger.kernel.org
Cc: Felix Fietkau <nbd@nbd.name>,
Lorenzo Bianconi <lorenzo@kernel.org>,
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>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Russell King <linux@armlinux.org.uk>,
Mason Chang <mason-cw.chang@mediatek.com>,
Frank Wunderlich <frank-w@public-files.de>,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net-next v3 0/2] net: ethernet: mtk_eth_soc: 9K jumbo frame support
Date: Sun, 8 Nov 2026 22:38:19 +0200 [thread overview]
Message-ID: <patch-aad4cfa8d9522d1f7dbc9893ea12e813@loljews.com> (raw)
This series makes the MediaTek SoC ethernet driver support 9K jumbo
frames on the 10G XGMII MACs (MT7988). The driver advertises a 2030-byte
max_mtu and programs the MAC max-rx field for at most 2048 bytes, so
MTU > 2K is rejected and 9K frames are not usable.
Patch 1 gates page_pool on the descriptor length of the ring: the pool
hands out order-0 pages and maps at most MTK_PP_MAX_BUF_SIZE, so a ring
whose descriptor length is larger has to use the
netdev_alloc_frag()/mtk_max_lro_buf_alloc() path. It is pure
preparation, every ring fits today.
Patch 2 adds the MTK_NETSYS_RX_9K capability, advertises 9K max_mtu on
the XGMII MACs (from the DT phy_mode at probe, so DSA can raise the
conduit MTU before the netdev is opened), programs XMAC_RX_CFG2 and the
PDMA RX SDL, derives the shared RX buffer length from the largest MTU,
sizes the RX rings from it and keeps the MAC max-rx limits in sync with
it. A runtime MTU change that needs larger buffers is rejected with
-EBUSY while DMA is running; shrinking is allowed.
This work is a forward-port of the MediaTek downstream jumbo work: Mason
Chang's "change default rx buffer length" and "add 9k jumbo frame
support" (MediaTek OpenWrt feed 999-eth-30/31, carried in
frank-w/BPI-Router-Linux), plus Frank Wunderlich's "try to fix crash the
right way". The runtime reallocation of Mason's "dynamic rx buffer
adjustment" (feed 999-eth-33) is not included and will be sent
separately.
The equivalent change was tested on a BPI-R4 Pro 8X (MT7988, 10G lan6 /
MxL86252) on the 6.18.60 backport: with both ends at MTU 9000, 8K ICMP
passes and iperf3 with MSS 8900 reaches ~9.87 Gbit/s (vs ~2.57 Gbit/s at
MSS 1460); the DSA conduit is raised to 9004 at boot. This v7.3 series
is compile-tested with CONFIG_NET_MEDIATEK_SOC=y and COMPILE_TEST=y; no
hardware run of this exact tree yet.
Changes in v3:
- gate page_pool on ring->buf_size <= MTK_PP_MAX_BUF_SIZE instead of
ring->frag_size <= PAGE_SIZE: frag_size uses the netdev_alloc_frag()
layout, so a ring could pass the old test while its descriptor length
was already larger than the pool can map;
- keep 2K as the minimum RX buffer length, so MTUs up to 2K keep working
at runtime on every SoC, DSA user ports included;
- restore MT7628's 1518 max_mtu, which v2 dropped by accident;
- in mtk_change_mtu() reject only a change that needs larger buffers, so
a lowered MTU no longer locks the port out of further changes;
- program XMAC_RX_CFG2 with read-modify-write, keeping the bits outside
the length field;
- replace the PDMA RX SDL field instead of OR-ing into it, which grew on
every open with a different MTU;
- rewrite the MAC max-rx limits on every mac_config(), so a reopen with a
smaller MTU narrows MACs that still carry the old limit;
- derive the XDP admission checks from the shared RX buffer length, so a
program cannot attach and then never run;
- correct the commit messages: no runtime reallocation is included, and
mtk_hw_init() now uses the shared length too;
- keep Simon Horman's Reviewed-by on 1/2 only, as 2/2 changed materially.
The order-2 allocation cost at 9K (one buffer per slot, high-order
GFP_ATOMIC refill) is unchanged from the downstream design and is called
out in the commit message.
v2: https://lore.kernel.org/all/patch-2793186c653124c4c0b3d463bde2ea3a@loljews.com/
v1: https://lore.kernel.org/all/patch-4f863a941889f0bceca1c082f2d79624@loljews.com/
Sandeep Haemoon (2):
net: ethernet: mtk_eth_soc: skip page_pool for RX rings it cannot back
net: ethernet: mtk_eth_soc: add 9K jumbo frame support
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 215 +++++++++++++++-----
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 10 +-
2 files changed, 173 insertions(+), 52 deletions(-)
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
--
2.53.0
next reply other threads:[~2026-11-08 21:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 20:38 Sandeep Haemoon [this message]
2026-11-08 20:37 ` [PATCH net-next v3 1/2] net: ethernet: mtk_eth_soc: skip page_pool Sandeep Haemoon
2026-11-09 22:19 ` netdev-bot+sashiko
2026-11-09 22:19 ` netdev-bot+sashiko
2026-11-08 20:38 ` [PATCH net-next v3 2/2] net: ethernet: mtk_eth_soc: add 9K jumbo Sandeep Haemoon
2026-11-09 22:19 ` netdev-bot+sashiko
2026-11-09 22:19 ` 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=patch-aad4cfa8d9522d1f7dbc9893ea12e813@loljews.com \
--to=sandeeph@loljews.com \
--cc=andrew+netdev@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=frank-w@public-files.de \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo@kernel.org \
--cc=mason-cw.chang@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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.