netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).