[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKK4Si92z91ACV_mgh4vqbecxQCHmB-SYEbq6Bsqei_Qg@mail.gmail.com>
Date: Wed, 31 May 2023 06:25:33 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: kuba@...nel.org, davem@...emloft.net, dsahern@...nel.org,
kuni1840@...il.com, netdev@...r.kernel.org, pabeni@...hat.com,
willemdebruijn.kernel@...il.com
Subject: Re: [PATCH v1 net-next 00/14] udp: Farewell to UDP-Lite.
On Wed, May 31, 2023 at 3:01 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
>
> From: Jakub Kicinski <kuba@...nel.org>
> Date: Tue, 30 May 2023 15:14:01 -0700
> > On Tue, 30 May 2023 16:16:20 -0400 Willem de Bruijn wrote:
> > > Is it a significant burden to keep the protocol, in case anyone is
> > > willing to maintain it?
> > >
> > > If consensus is that it is time to remove, a warning may not be
> > > sufficient for people to notice.
> > >
> > > Perhaps break it, but in a way that can be undone trivially,
> > > preferably even without recompiling the kernel. Say, returning
> > > EOPNOTSUPP on socket creation, unless a sysctl has some magic
> > > non-deprecated value. But maybe I'm overthinking it. There must be
> > > prior art for this?
> >
> > It may be the most intertwined feature we attempted to remove.
> > UFO was smaller, right?
> >
> > Did deprecation warnings ever work?
> >
> > How about we try to push a WARN_ONCE() on socket creation to net and
> > stable? With a message along the lines of "UDP lite is assumed to have
> > no users, and is been deleted, please contact netdev@.."
> >
> > Then delete the whole thing in net-next? Hopefully pushing to stable
> > would expedite user reports? We'll find out if Greg throws rotten fruit
> > at us or not..
>
> Yes, if it's ok, it would be better to add a WARN_ONCE() to stable.
>
> If we added it only in net-next, no one might notice it and we could
> remove UDP-Lite before the warning is available in the next LTS stable
> tree.
WARN_ONCE() will fire a syzbot report.
Honestly I do not think UDP-Lite is a significant burden.
What about instead adding a CONFIG_UDPLITE and default it to
"CONFIG_UDPLITE is not set" ?
And add a static key, with /proc/sys/net/core/udplite_enable to
eventually save some cycles in various fast paths
and let the user opt-in, in case it is using a distro kernel. with
CONFIG_UDPLITE=y
DCCP is more interesting because removing it would allow for a better
organisation of tcp fields to reduce
number of cache lines hit in the fast path.
Powered by blists - more mailing lists