From: Ralf Lici <ralf@mandelbit.com>
To: Xavier HSINYUAN <XavierHsinyuan@outlook.com>
Cc: andrew+netdev@lunn.ch, antonio@mandelbit.com,
davem@davemloft.net, dxld@darkboxed.org, edumazet@google.com,
kuba@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, pabeni@redhat.com
Subject: Re: [RFC net-next 10/15] ipxlat: add 4to6 pre-fragmentation path
Date: Fri, 5 Jun 2026 14:24:27 +0200 [thread overview]
Message-ID: <20260605122428.402982-1-ralf@mandelbit.com> (raw)
In-Reply-To: <TYRPR01MB1266606B1144F3896FC712C3CCA032@TYRPR01MB12666.jpnprd01.prod.outlook.com>
On Mon, 18 May 2026 20:36:25 +0800, Xavier HSINYUAN <XavierHsinyuan@outlook.com> wrote:
> Hi Ralf,
>
Hi Xavier,
Sorry for the slow reply. This got buried while I was busy with other
kernel work.
> >+int ipxlat_46_plan_prefrag(struct ipxlat_priv *ipxlat, struct sk_buff *skb)
> >+{
> >+ unsigned int pkt_len6, pmtu6, threshold6, frag_max_size, pkt_len4,
> >+ old_l3_len, new_l3_len;
> >+ struct ipxlat_cb *cb = ipxlat_skb_cb(skb);
> >+ const struct iphdr *in4 = ip_hdr(skb);
> >+ int l3_delta, frag_l3_delta;
> >+
> >+ if (unlikely(cb->frag_max_size)) {
> >+ DEBUG_NET_WARN_ON_ONCE(1);
> >+ cb->frag_max_size = 0;
> >+ }
> >+
> >+ pkt_len4 = iph_totlen(skb, in4);
> >+ old_l3_len = cb->l3_hdr_len;
> >+ new_l3_len = sizeof(struct ipv6hdr) +
> >+ (ip_is_fragment(in4) ? sizeof(struct frag_hdr) : 0);
> >+ l3_delta = (int)new_l3_len - (int)old_l3_len;
> >+ pkt_len6 = pkt_len4 + l3_delta;
> >+
> >+ pmtu6 = ipxlat_46_lookup_pmtu6(ipxlat, skb, in4);
> >+ threshold6 = min(pmtu6, READ_ONCE(ipxlat->lowest_ipv6_mtu));
> >+
> >+ if (likely(pkt_len6 <= threshold6))
> >+ return 0;
> >+
> >+ /* df packets are never locally pre-fragmented */
> >+ if (likely(be16_to_cpu(in4->frag_off) & IP_DF)) {
> >+ /* Let the IPv6 forwarding path raise PTB when needed and rely
> >+ * on the reverse 6->4 ICMP translation path for feedback.
> >+ */
> >+ return 0;
> >+ }
>
> How about putting the DF check before the PMTU lookup?
> ipxlat_46_lookup_pmtu6() requires ip6_route_output() and dst_release(),
> but the DF bit is much cheaper to test and is typically set on most
> TCP/QUIC packets. It looks like a pure reorder but I have not verified
> it carefully.
>
Yes, that looks right to me. The PMTU lookup is only needed for the
non-DF path, where we may actually compute a pre-fragmentation cap. For
DF packets ipxlat_46_plan_prefrag should leave frag_max_size unset and
let the later IPv6 output path generate PTB if the translated packet is
too large.
I'll move the DF check before ipxlat_46_lookup_pmtu6, after the stale
frag_max_size clearing.
Thanks!
--
Ralf Lici
Mandelbit Srl
next prev parent reply other threads:[~2026-06-05 12:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 15:12 [RFC net-next 00/15] Introducing ipxlat: a stateless IPv4/IPv6 translation device Ralf Lici
2026-03-19 15:12 ` [RFC net-next 01/15] drivers/net: add ipxlat netdevice skeleton and build plumbing Ralf Lici
2026-03-19 15:12 ` [RFC net-next 02/15] ipxlat: add RFC 6052 address conversion helpers Ralf Lici
2026-03-19 15:12 ` [RFC net-next 03/15] ipxlat: add packet metadata control block helpers Ralf Lici
2026-03-19 15:12 ` [RFC net-next 04/15] ipxlat: add IPv4 packet validation path Ralf Lici
2026-03-19 15:12 ` [RFC net-next 05/15] ipxlat: add IPv6 " Ralf Lici
2026-04-09 2:18 ` Xavier HSINYUAN
2026-04-09 9:44 ` Ralf Lici
2026-03-19 15:12 ` [RFC net-next 06/15] ipxlat: add transport checksum and offload helpers Ralf Lici
2026-03-19 15:12 ` [RFC net-next 07/15] ipxlat: add 4to6 and 6to4 TCP/UDP translation helpers Ralf Lici
2026-03-19 15:12 ` [RFC net-next 08/15] ipxlat: add translation engine and dispatch core Ralf Lici
2026-06-04 18:23 ` Toke Høiland-Jørgensen
2026-06-05 12:32 ` Ralf Lici
2026-03-19 15:12 ` [RFC net-next 09/15] ipxlat: emit translator-generated ICMP errors on drop Ralf Lici
2026-03-19 15:12 ` [RFC net-next 10/15] ipxlat: add 4to6 pre-fragmentation path Ralf Lici
2026-05-18 12:36 ` Xavier HSINYUAN
2026-06-05 12:24 ` Ralf Lici [this message]
2026-03-19 15:12 ` [RFC net-next 11/15] ipxlat: add ICMP informational translation paths Ralf Lici
2026-03-19 15:12 ` [RFC net-next 12/15] ipxlat: add ICMP error translation and quoted-inner handling Ralf Lici
2026-03-19 15:12 ` [RFC net-next 13/15] ipxlat: add netlink control plane and uapi Ralf Lici
2026-03-19 15:12 ` [RFC net-next 14/15] selftests: net: add ipxlat coverage Ralf Lici
2026-03-19 15:12 ` [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide Ralf Lici
2026-03-19 22:11 ` Jonathan Corbet
2026-03-24 9:55 ` Ralf Lici
2026-04-06 14:50 ` Xavier Hsinyuan
2026-04-07 11:30 ` Daniel Gröber
2026-04-09 2:17 ` Xavier HSINYUAN
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=20260605122428.402982-1-ralf@mandelbit.com \
--to=ralf@mandelbit.com \
--cc=XavierHsinyuan@outlook.com \
--cc=andrew+netdev@lunn.ch \
--cc=antonio@mandelbit.com \
--cc=davem@davemloft.net \
--cc=dxld@darkboxed.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox