From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Alexander Potapenko <glider@google.com>,
Yury Norov <yury.norov@gmail.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: Tue, 19 Dec 2023 10:04:02 +0100 [thread overview]
Message-ID: <978883c1-ffaa-413f-87f9-1956108f0d60@intel.com> (raw)
In-Reply-To: <CAG_fn=XOguL_++vJk2kFQoxu1msLzFBB5sJiD8Jxr4oUZ7qZ7g@mail.gmail.com>
From: Alexander Potapenko <glider@google.com>
Date: Mon, 18 Dec 2023 17:16:09 +0100
> On Mon, Dec 18, 2023 at 4:57 PM Yury Norov <yury.norov@gmail.com> wrote:
>>
>> + Alexander Potapenko
>>
>> On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote:
[...]
>>> 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.
>
> Yeah, sorry about that. Because the MTE part of the patches was still
> awaiting review, I thought it would be better to land the bitmap API
> separately, but as you pointed out there should be at least one user
> for it, which it wouldn't have in that case.
>
> I don't have a strong preference about whether to submit the patches
> before or after the end of year - in fact I don't think they are
> urgent enough, and we'd better postpone them till January.
>
> So unless Alexander has urgent fixes depending on my bitmap patches,
> I'd suggest waiting till they are taken via the arm64 tree.
No, nothing urgent. Sounds good, no need to rush at the end of the dev
cycle.
>
>> 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,
Olek
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Alexander Potapenko <glider@google.com>,
Yury Norov <yury.norov@gmail.com>
Cc: Marcin Szycik <marcin.szycik@linux.intel.com>,
Jakub Kicinski <kuba@kernel.org>, <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>, <pabeni@redhat.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
<michal.swiatkowski@linux.intel.com>, <wojciech.drewek@intel.com>,
<idosch@nvidia.com>, <jesse.brandeburg@intel.com>,
<intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>,
<jiri@resnulli.us>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support
Date: Tue, 19 Dec 2023 10:04:02 +0100 [thread overview]
Message-ID: <978883c1-ffaa-413f-87f9-1956108f0d60@intel.com> (raw)
In-Reply-To: <CAG_fn=XOguL_++vJk2kFQoxu1msLzFBB5sJiD8Jxr4oUZ7qZ7g@mail.gmail.com>
From: Alexander Potapenko <glider@google.com>
Date: Mon, 18 Dec 2023 17:16:09 +0100
> On Mon, Dec 18, 2023 at 4:57 PM Yury Norov <yury.norov@gmail.com> wrote:
>>
>> + Alexander Potapenko
>>
>> On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote:
[...]
>>> 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.
>
> Yeah, sorry about that. Because the MTE part of the patches was still
> awaiting review, I thought it would be better to land the bitmap API
> separately, but as you pointed out there should be at least one user
> for it, which it wouldn't have in that case.
>
> I don't have a strong preference about whether to submit the patches
> before or after the end of year - in fact I don't think they are
> urgent enough, and we'd better postpone them till January.
>
> So unless Alexander has urgent fixes depending on my bitmap patches,
> I'd suggest waiting till they are taken via the arm64 tree.
No, nothing urgent. Sounds good, no need to rush at the end of the dev
cycle.
>
>> 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,
Olek
next prev parent reply other threads:[~2023-12-19 9:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 16:49 [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 1/7] ip_tunnel: use a separate struct to store tunnel params in the kernel Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 2/7] ip_tunnel: convert __be16 tunnel flags to bitmaps Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 3/7] lib/bitmap: add tests for IP tunnel flags conversion helpers Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 4/7] pfcp: add PFCP module Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 5/7] pfcp: always set pfcp metadata Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 6/7] ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-07 16:49 ` [Intel-wired-lan] [PATCH iwl-next v4 7/7] ice: Add support for PFCP hardware offload in switchdev Marcin Szycik
2023-12-07 16:49 ` Marcin Szycik
2023-12-08 21:34 ` [Intel-wired-lan] [PATCH iwl-next v4 0/7] Add PFCP filter support Tony Nguyen
2023-12-08 21:34 ` Tony Nguyen
2023-12-11 12:38 ` Alexander Lobakin
2023-12-11 12:38 ` Alexander Lobakin
2023-12-11 21:23 ` Tony Nguyen
2023-12-11 21:23 ` Tony Nguyen
2023-12-12 10:45 ` Marcin Szycik
2023-12-12 10:45 ` Marcin Szycik
2023-12-15 10:11 ` Alexander Lobakin
2023-12-15 10:11 ` Alexander Lobakin
2023-12-15 16:49 ` Jakub Kicinski
2023-12-15 16:49 ` Jakub Kicinski
2023-12-18 10:04 ` Marcin Szycik
2023-12-18 10:04 ` Marcin Szycik
2023-12-18 12:47 ` Alexander Lobakin
2023-12-18 12:47 ` Alexander Lobakin
2023-12-18 15:57 ` Yury Norov
2023-12-18 15:57 ` Yury Norov
2023-12-18 16:16 ` Alexander Potapenko
2023-12-18 16:16 ` Alexander Potapenko
2023-12-19 9:04 ` Alexander Lobakin [this message]
2023-12-19 9:04 ` Alexander Lobakin
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=978883c1-ffaa-413f-87f9-1956108f0d60@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=glider@google.com \
--cc=idosch@nvidia.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=marcin.szycik@linux.intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=wojciech.drewek@intel.com \
--cc=yury.norov@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.