[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO3-PbqtEPQro4wsQbaD-UbF-2RpxsVKVvs3M0X10-oE7K1LXA@mail.gmail.com>
Date: Fri, 20 Oct 2023 01:39:31 -0500
From: Yan Zhai <yan@...udflare.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
David Ahern <dsahern@...nel.org>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Aya Levin <ayal@...dia.com>,
Tariq Toukan <tariqt@...dia.com>, linux-kernel@...r.kernel.org,
kernel-team@...udflare.com, Florian Westphal <fw@...len.de>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Alexander H Duyck <alexander.duyck@...il.com>
Subject: Re: [PATCH v3 net-next 1/3] ipv6: remove dst_allfrag test on ipv6 output
On Fri, Oct 20, 2023 at 1:06 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Oct 20, 2023 at 7:32 AM Yan Zhai <yan@...udflare.com> wrote:
> >
> > dst_allfrag was added before the first git commit:
> >
> > https://www.mail-archive.com/bk-commits-head@vger.kernel.org/msg03399.html
> >
> > The feature would send packets to the fragmentation path if a box
> > receives a PMTU value with less than 1280 byte. However, since commit
> > 9d289715eb5c ("ipv6: stop sending PTB packets for MTU < 1280"), such
> > message would be simply discarded. The feature flag is neither supported
> > in iproute2 utility. In theory one can still manipulate it with direct
> > netlink message, but it is not ideal because it was based on obsoleted
> > guidance of RFC-2460 (replaced by RFC-8200).
> >
> > The feature test would always return false at the moment, so remove it
> > from the output path.
>
> What about other callers of dst_allfrag() ?
>
> This feature seems broken atm.
It is broken as far as I can tell. The reason I removed just one
caller here is to keep the code simpler and consistent. If I don't do
so, I ought to test it for both GSO fast path and slow path to be
logically consistent. Seems an overkill to me. For the removal of the
rest, I'd hope it could come in as a standalone patch(set) because it
is not just callers but also those unnecessary flags and tests on IP
corks and sockets, not quite aligned with this patch's intention. I
noted you have drafted something like this in the past:
https://lkml.kernel.org/netdev/1335348157.3274.30.camel@edumazet-glaptop/
I guess it might be a good base point to work on as a new patch(set)?
What's your call on this?
Yan
Powered by blists - more mailing lists