Message-ID: <ZTJ2iKk3sBFzVQJl@yury-ThinkPad>
Date: Fri, 20 Oct 2023 05:46:00 -0700
From: Yury Norov <yury.norov@...il.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Alexander Potapenko <glider@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	David Ahern <dsahern@...nel.org>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Simon Horman <simon.horman@...igine.com>, netdev@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-btrfs@...r.kernel.org, dm-devel@...hat.com,
	ntfs3@...ts.linux.dev, linux-s390@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/13] ip_tunnel: convert __be16 tunnel flags to
 bitmaps

+ Stephen

On Mon, Oct 16, 2023 at 10:55:02AM -0700, Yury Norov wrote:
> On Mon, Oct 16, 2023 at 06:52:34PM +0200, Alexander Lobakin wrote:
> > Based on top of "Implement MTE tag compression for swapped pages"[0]
> > from Alexander Potapenko as it uses its bitmap_{read,write}() functions
> > to not introduce another pair of similar ones.
> > 
> > Derived from the PFCP support series[1] as this grew bigger (2 -> 13
> > commits) and involved more core bitmap changes. Only commits 10 and 11
> > are from the mentioned tree, the rest is new. PFCP itself still depends
> > on this series.
> > 
> > IP tunnels have their flags defined as `__be16`, including UAPI, and
> > after GTP was accepted, there are no more free bits left. UAPI (incl.
> > direct usage of one of the user structs) and explicit Endianness only
> > complicate things.
> > Since it would either way end up with hundreds of locs due to all that,
> > pick bitmaps right from the start to store the flags in the most native
> > and scalable format with rich API. I don't think it's worth trying to
> > praise luck and pick smth like u32 only to redo everything in x years :)
> > More details regarding the IP tunnel flags is in 11 and 13.
> > 
> > The rest is just a good bunch of prereqs and tests: a couple of new
> > helpers and extensions to the old ones, a few optimizations to partially
> > mitigate IP tunnel object code growth due to __be16 -> long, and
> > decouping one UAPI struct used throughout the whole kernel into the
> > userspace and the kernel space counterparts to eliminate the dependency.
> > 
> > [0] https://lore.kernel.org/lkml/20231011172836.2579017-1-glider@google.com
> > [1] https://lore.kernel.org/netdev/20230721071532.613888-1-marcin.szycik@linux.intel.com

[...]

> > ---
> > Not sure whether it's fine to have that all in one series, but OTOH
> > there's not much stuff I could split (like, 3 commits), it either
> > depends directly (new helpers etc.) or will just generate suboptimal
> > code w/o some of the commits.
> > 
> > I'm also thinking of which tree this would ideally be taken through.
> > The main subject is networking, but most of the commits are generic.
> > My idea is to push this via Yury / bitmaps and then ask the netdev
> > maintainers to pull his tree before they take PFCP (dependent on this
> > one).
> 
> Let's wait for more comments, but I'm generally OK with the generic
> part, and have nothing against moving it, or the whole series, through
> bitmap-for-next.

I put this into bitmap-for-next, and it caused build failures for
Stephen:

https://lore.kernel.org/lkml/20220722191657.1d7282c2@canb.auug.org.au/

I can reproduce them too. So, removing from -next. Alexander, can you
run another round with all found issues fixed?

Thanks,
Yury

Powered by blists - more mailing lists