From: Jakub Kicinski <kuba@kernel.org>
To: "Maciej Żenczykowski" <maze@google.com>
Cc: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Linux NetDev <netdev@vger.kernel.org>,
Stefano Brivio <sbrivio@redhat.com>,
Kaustubh Pandey <quic_kapandey@quicinc.com>,
Sean Tranchetti <quic_stranche@quicinc.com>
Subject: Re: [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev mtu
Date: Thu, 16 Jun 2022 09:42:16 -0700 [thread overview]
Message-ID: <20220616094216.3bc9aef2@kernel.org> (raw)
In-Reply-To: <CANP3RGdRD=U7OAwrcdp1XUXFcb5b1zTfoy1fxa8JZUcnxBdsKg@mail.gmail.com>
On Thu, 16 Jun 2022 00:33:02 -0700 Maciej Żenczykowski wrote:
> On Wed, Jun 15, 2022 at 10:36 PM Subash Abhinov Kasiviswanathan (KS) <quic_subashab@quicinc.com> wrote:
> > >> CC maze, please add him if there is v3
> > >>
> > >> I feel like the problem is with the fact that link mtu resets protocol
> > >> MTUs. Nothing we can do about that, so why not set link MTU to 9k (or
> > >> whatever other quantification of infinity there is) so you don't have
> > >> to touch it as you discover the MTU for v4 and v6?
> >
> > That's a good point.
>
> Because link mtu affects rx mtu which affects nic buffer allocations.
> Somewhere in the vicinity of mtu 1500..2048 your packets stop fitting
> in 2kB of memory and need 4kB (or more)
I was afraid someone would point that out :) Luckily the values Subash
mentioned were both under 2k, and hope fully the device can do scatter?
🤞😟 (Don't modems do LRO or some other form of aggregation usually?)
> > >> My worry is that the tweaking of the route MTU update heuristic will
> > >> have no end.
> > >>
> > >> Stefano, does that makes sense or you think the change is good?
> >
> > The only concern is that current behavior causes the initial packets
> > after interface MTU increase to get dropped as part of PMTUD if the IPv6
> > PMTU itself didn't increase. I am not sure if that was the intended
> > behavior as part of the original change. Stefano, could you please confirm?
> >
> > > I vaguely recall that if you don't want device mtu changes to affect
> > > ipv6 route mtu, then you should set 'mtu lock' on the routes.
> > > (this meaning of 'lock' for v6 is different than for ipv4, where
> > > 'lock' means transmit IPv4/TCP with Don't Frag bit unset)
> >
> > I assume 'mtu lock' here refers to setting the PMTU on the IPv6 routes
> > statically. The issue with that approach is that router advertisements
> > can no longer update PMTU once a static route is configured.
>
> yeah. Hmm should RA generated routes use locked mtu too?
> I think the only reason an RA generated route would have mtu information
> is for it to stick...
If link MTU is lower than RA MTU do we do min() or ignore the RA MTU?
next prev parent reply other threads:[~2022-06-16 16:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 5:01 [PATCH net v2 0/2] net: ipv6: Update route MTU behavior Subash Abhinov Kasiviswanathan
2022-06-14 5:01 ` [PATCH net v2 1/2] ipv6: Honor route mtu if it is within limit of dev mtu Subash Abhinov Kasiviswanathan
2022-06-14 12:27 ` Stefano Brivio
2022-06-14 18:34 ` Subash Abhinov Kasiviswanathan (KS)
2022-06-16 0:35 ` Jakub Kicinski
2022-06-16 1:21 ` Maciej Żenczykowski
2022-06-16 5:36 ` Subash Abhinov Kasiviswanathan (KS)
2022-06-16 7:33 ` Maciej Żenczykowski
2022-06-16 16:42 ` Jakub Kicinski [this message]
2022-06-16 17:08 ` Maciej Żenczykowski
2022-06-16 13:39 ` Stefano Brivio
2022-06-14 5:01 ` [PATCH net v2 2/2] tools: selftests: Update tests for new IPv6 route MTU behavior Subash Abhinov Kasiviswanathan
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=20220616094216.3bc9aef2@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=maze@google.com \
--cc=netdev@vger.kernel.org \
--cc=quic_kapandey@quicinc.com \
--cc=quic_stranche@quicinc.com \
--cc=quic_subashab@quicinc.com \
--cc=sbrivio@redhat.com \
--cc=yoshfuji@linux-ipv6.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 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.