Re: [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support

From: Yury Norov <yury.norov@gmail.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>,
	Alexander Potapenko <glider@google.com>
Cc: jiri@resnulli.us, wojciech.drewek@intel.com, idosch@nvidia.com,
	jesse.brandeburg@intel.com, Eric Dumazet <edumazet@google.com>,
	Marcin Szycik <marcin.szycik@linux.intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	michal.swiatkowski@linux.intel.com,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
	intel-wired-lan@lists.osuosl.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support
Date: Mon, 18 Dec 2023 07:57:43 -0800	[thread overview]
Message-ID: <ZYBr98sd+XzSfy9v@yury-ThinkPad> (raw)
In-Reply-To: <1eb475bb-d2ba-4cf3-a2ce-36263b61b5ff@intel.com>

+ Alexander Potapenko

On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote:
> From: Marcin Szycik <marcin.szycik@linux.intel.com>
> Date: Mon, 18 Dec 2023 11:04:01 +0100
> 
> > 
> > 
> > On 15.12.2023 17:49, Jakub Kicinski wrote:
> >> On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote:
> >>> Ping? :s
> >>> Or should we resubmit?
> >>
> >> Can you wait for next merge window instead?
> >> We're getting flooded with patches as everyone seemingly tries to get
> >> their own (i.e. the most important!) work merged before the end of 
> >> the year. The set of PRs from the bitmap tree which Linus decided
> >> not to pull is not empty. So we'd have to go figure out what's exactly
> >> is in that branch we're supposed to pull, and whether it's fine.
> >> It probably is, but you see, this is a problem which can be solved by
> >> waiting, and letting Linus pull it himself. While the 150 patches we're
> >> getting a day now have to be looked at.
> > 
> > Let's wait to the next window then.
> 
> Hey Yury,
> 
> Given that PFCP will be resent in the next window...
> 
> Your "boys" tree is in fact self-contained -- those are mostly
> optimizations and cleanups, and for the new API -- bitmap_{read,write}()
> -- it has internal users (after "bitmap: make bitmap_{get,set}_value8()
> use bitmap_{read,write}()"). IOW, I don't see a reason for not merging
> it into your main for-next tree (this week :p).
> What do you think?

I think that there's already enough mess with this patch. Alexander
submitted new version of his MTE series together with the patch.

https://lore.kernel.org/lkml/ZXtciaxTKFBiui%2FX@yury-ThinkPad/T/

Now you're asking me to merge it separately. I don't want to undercut
arm64 folks.

Can you guys decide what you want? If you want to move
bitmap_read/write() with my branch, I need to send it in -next for
testing ASAP. And for that, as I already said, I need at least one
active user in current kernel tree. (Yes, bitmap_get_value8() counts.)

If you want to move it this way, please resend all the patches
together.

Thanks,
Yury
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan