From: Mariusz Klimek <maklimek97@gmail.com>
To: netdev@vger.kernel.org
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, dsahern@kernel.org,
idosch@nvidia.com, ncardwell@google.com, shuah@kernel.org,
kuniyu@google.com, alice@isovalent.com,
Mariusz Klimek <maklimek97@gmail.com>
Subject: [PATCH net-next 02/10] ipv6: allow route exceptions with MTUs above 65535
Date: Mon, 8 Jun 2026 15:07:47 +0200 [thread overview]
Message-ID: <20260608130755.5626-3-maklimek97@gmail.com> (raw)
In-Reply-To: <20260608130755.5626-1-maklimek97@gmail.com>
This patch allows route exceptions to specify an MTU above 65535 so that
PMTU discovery can settle on an PMTU above 65535 (if the MTUs along the
path allow for it).
IP6_MAX_JUMBOGRAM_MTU is set to INT_MAX rather than UINT_MAX because MTU
values and packet lengths are sometimes stored as signed integers.
Signed-off-by: Mariusz Klimek <maklimek97@gmail.com>
---
include/linux/ipv6.h | 6 ++++++
include/net/ip6_route.h | 5 +++--
net/ipv6/route.c | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index a7421382a916..201c1615ac8e 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -196,6 +196,12 @@ static inline bool ipv6_l3mdev_skb(__u16 flags)
#define IP6CB(skb) ((struct inet6_skb_parm*)((skb)->cb))
#define IP6CBMTU(skb) ((struct ip6_mtuinfo *)((skb)->cb))
+/* IPv6 jumbogram payload length is stored into a 32bit field, but cap the max
+ * MTU to INT_MAX because MTUs and packet lengths are sometimes represented as
+ * signed ints.
+ */
+#define IP6_MAX_JUMBOGRAM_MTU INT_MAX
+
static inline int inet6_iif(const struct sk_buff *skb)
{
bool l3_slave = ipv6_l3mdev_skb(IP6CB(skb)->flags);
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 09ffe0f13ce7..9c9fbf881235 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -38,8 +38,9 @@ struct route_info {
#define RT6_LOOKUP_F_IGNORE_LINKSTATE 0x00000040
#define RT6_LOOKUP_F_DST_NOREF 0x00000080
-/* We do not (yet ?) support IPv6 jumbograms (RFC 2675)
- * Unlike IPv4, hdr->seg_len doesn't include the IPv6 header
+/* We do not (yet ?) fully support IPv6 jumbograms (RFC 2675) for all protocols.
+ * Where jumbograms are supported, IP6_MAX_JUMBOGRAM_MTU should be used instead.
+ * Unlike IPv4, hdr->seg_len doesn't include the IPv6 header.
*/
#define IP6_MAX_MTU (0xFFFF + sizeof(struct ipv6hdr))
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 636f0120d7e3..ac38771c49cd 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1656,7 +1656,7 @@ static unsigned int fib6_mtu(const struct fib6_result *res)
rcu_read_unlock();
}
- mtu = min_t(unsigned int, mtu, IP6_MAX_MTU);
+ mtu = min_t(unsigned int, mtu, IP6_MAX_JUMBOGRAM_MTU);
return mtu - lwtunnel_headroom(nh->fib_nh_lws, mtu);
}
--
2.47.3
next prev parent reply other threads:[~2026-06-08 13:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260608130755.5626-1-maklimek97@gmail.com>
2026-06-08 13:07 ` [PATCH net-next 01/10] ipv6: do not fragment packets into jumbograms Mariusz Klimek
2026-06-08 13:07 ` Mariusz Klimek [this message]
2026-06-08 13:07 ` [PATCH net-next 03/10] ipv6: add jumbo payload option to non-gso jumbograms Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 04/10] tcp: decouple TSO segment length from MSS Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 05/10] tcp: split jumbograms with urgent pointer correctly Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 06/10] tcp: set MSS correctly for PMTU above 65535 Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 07/10] veth: raise the max MTU " Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 08/10] selftests/net: test sending TCP jumbograms over veth Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 09/10] selftests/net: add test cases with MTU above 65535 to big_tcp.sh Mariusz Klimek
2026-06-08 13:07 ` [PATCH net-next 10/10] selftests/net: add jumbogram test case to msg_zerocopy.sh Mariusz Klimek
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=20260608130755.5626-3-maklimek97@gmail.com \
--to=maklimek97@gmail.com \
--cc=alice@isovalent.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox