[ANN] netdev call - Jan 16th

[ANN] netdev call - Jan 16th

[Jakub Kicinski]

Hi,

The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).

There's a minor CI update. Please suggest other topics.

Re: [ANN] netdev call - Jan 16th

[Andy Gospodarek]

On Mon, Jan 15, 2024 at 05:54:40PM -0800, Jakub Kicinski wrote:
> Hi,
> 
> The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
> 
> There's a minor CI update. Please suggest other topics.
> 

I would like to discuss a process question for posting a fix to a stable kernel
that isn't needed in the latest upstream as it was fixed another way.

This is related to this thread:

https://lore.kernel.org/linux-patches/ZZQqGtYqN3X9EuWo@C02YVCJELVCG.dhcp.broadcom.net/

Thanks.

Re: [ANN] netdev call - Jan 16th

[John Fastabend]

Andy Gospodarek wrote:
> On Mon, Jan 15, 2024 at 05:54:40PM -0800, Jakub Kicinski wrote:
> > Hi,
> > 
> > The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> > is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
> > 
> > There's a minor CI update. Please suggest other topics.
> > 
> 
> I would like to discuss a process question for posting a fix to a stable kernel
> that isn't needed in the latest upstream as it was fixed another way.
> 
> This is related to this thread:
> 
> https://lore.kernel.org/linux-patches/ZZQqGtYqN3X9EuWo@C02YVCJELVCG.dhcp.broadcom.net/
> 
> Thanks.
> 

If you send it to stable with a tag like,

  CC: <stable@vger.kernel.org> # 5.15.x

or whatever kernel you need this has worked from me. This has worked for
me if I understood the above question correctly. The relevant docs are in
Documentation/process/stable-kernel-rules.rst. The following bit seems to
explain it.

 * For patches that may have kernel version prerequisites specify them using
   the following format in the sign-off area:

   .. code-block:: none

     Cc: <stable@vger.kernel.org> # 3.3.x

   The tag has the meaning of:

   .. code-block:: none

     git cherry-pick <this commit>

   For each "-stable" tree starting with the specified version.

   Note, such tagging is unnecessary if the stable team can derive the
   appropriate versions from Fixes: tags.

 * To delay pick up of patches, use the following format:

   .. code-block:: none

     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline

 * For any other requests, just add a note to the stable tag. This for example
   can be used to point out known problems:

   .. code-block:: none

     Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3

Re: [ANN] netdev call - Jan 16th

[Andy Gospodarek]

On Tue, Jan 16, 2024 at 07:29:19AM -0800, John Fastabend wrote:
> Andy Gospodarek wrote:
> > On Mon, Jan 15, 2024 at 05:54:40PM -0800, Jakub Kicinski wrote:
> > > Hi,
> > > 
> > > The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> > > is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
> > > 
> > > There's a minor CI update. Please suggest other topics.
> > > 
> > 
> > I would like to discuss a process question for posting a fix to a stable kernel
> > that isn't needed in the latest upstream as it was fixed another way.
> > 
> > This is related to this thread:
> > 
> > https://lore.kernel.org/linux-patches/ZZQqGtYqN3X9EuWo@C02YVCJELVCG.dhcp.broadcom.net/
> > 
> > Thanks.
> > 
> 
> If you send it to stable with a tag like,
> 
>   CC: <stable@vger.kernel.org> # 5.15.x
> 
> or whatever kernel you need this has worked from me. This has worked for
> me if I understood the above question correctly. The relevant docs are in
> Documentation/process/stable-kernel-rules.rst. The following bit seems to
> explain it.
> 
>  * For patches that may have kernel version prerequisites specify them using
>    the following format in the sign-off area:
> 
>    .. code-block:: none
> 
>      Cc: <stable@vger.kernel.org> # 3.3.x
> 
>    The tag has the meaning of:
> 
>    .. code-block:: none
> 
>      git cherry-pick <this commit>
> 
>    For each "-stable" tree starting with the specified version.
> 
>    Note, such tagging is unnecessary if the stable team can derive the
>    appropriate versions from Fixes: tags.
> 
>  * To delay pick up of patches, use the following format:
> 
>    .. code-block:: none
> 
>      Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
> 
>  * For any other requests, just add a note to the stable tag. This for example
>    can be used to point out known problems:
> 
>    .. code-block:: none
> 
>      Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3

Thanks, John.

This one is a bit odd what happened is that by the time this problem was
reported (on an older kernel), the code changed out from underneath.
The new code was bug-compatible with the old code (whic is an indicator
that a good job was done porting bnxt_en to use DMA mapping from the
page pool infra.

So at the time when the patch was posted, the tip of tree code did need
a fixes tag of:

Fixes: 578fcfd26e2a ("bnxt_en: Let the page pool manage the DMA mapping")

In any kernel pre-6.6 (or if we found the patch a few months back) the
patch would have been different (since the dma mapping was handled
differently) and the fixes tag would have been:

Fixes: a7559bc8c17c ("bnxt: support transmit and free of aggregation buffers")

Greg's concern (at least as I read it) is that it looks like I'm asking
him to take a patch that is not upstream.  That totally makes sense, but
now what?

Based on what I see in Documentation, I think I need to just resubmit to
stable as that would follow "Option 2" and explain why it 'deviates from
the original' patch.

Re: [ANN] netdev call - Jan 16th

[Andrew Lunn]

> Thanks, John.
> 
> This one is a bit odd what happened is that by the time this problem was
> reported (on an older kernel), the code changed out from underneath.

Hi Andy

Talk to Florian

He has dealt with Fixes like this in the past. It generally works out
fine so long as you are explicit about what is going on, in comments
under the ---. That, plus correctly marking what kernel version the
patch is for.

    Andrew

Re: [ANN] netdev call - Jan 16th

[Andy Gospodarek]

On Tue, Jan 16, 2024 at 05:10:31PM +0100, Andrew Lunn wrote:
> > Thanks, John.
> > 
> > This one is a bit odd what happened is that by the time this problem was
> > reported (on an older kernel), the code changed out from underneath.
> 
> Hi Andy
> 
> Talk to Florian
> 
> He has dealt with Fixes like this in the past. It generally works out
> fine so long as you are explicit about what is going on, in comments
> under the ---. That, plus correctly marking what kernel version the
> patch is for.
> 
>     Andrew

Will do!  I know where to find him!

Re: [ANN] netdev call - Jan 16th

[Florian Fainelli]

On 1/16/24 08:12, Andy Gospodarek wrote:
> On Tue, Jan 16, 2024 at 05:10:31PM +0100, Andrew Lunn wrote:
>>> Thanks, John.
>>>
>>> This one is a bit odd what happened is that by the time this problem was
>>> reported (on an older kernel), the code changed out from underneath.
>>
>> Hi Andy
>>
>> Talk to Florian
>>
>> He has dealt with Fixes like this in the past. It generally works out
>> fine so long as you are explicit about what is going on, in comments
>> under the ---. That, plus correctly marking what kernel version the
>> patch is for.
>>
>>      Andrew
> 
> Will do!  I know where to find him!

Hi there! It looks like doing a "targeted" set of fixes for pre-6.6 
kernels is appropriate so you would just want to submit them with a 
[PATCH stable X.Y] subject to clearly denote which stable branch they 
apply against, and have a cover letter that explains why.
-- 
Florian

Re: [ANN] netdev call - Jan 16th

[Jakub Kicinski]

On Mon, 15 Jan 2024 17:54:40 -0800 Jakub Kicinski wrote:
> The bi-weekly netdev call at https://bbb.lwn.net/b/jak-wkr-seg-hjn
> is scheduled tomorrow at 8:30 am (PT) / 5:30 pm (~EU).
> 
> There's a minor CI update. Please suggest other topics.

Sorry about the delay in sending minutes, here they are:

* BQL (Dave Taht)
  * Embedded drivers missing BQL
    * Complain to the driver maintainers
    * Driver review time is best to request basic features like BQL
    * Some of the problems are in the vendor downstream drivers
  * Are vendors running flent and other latency tests?
    * Jesse: yes, although they struggle at DC speeds
  * Multi-queue BQL
    * Not much interest among attendees
    * Andrew: try to keep it in the core, fewer driver changes the better
 * CI
   * Most of the networking selftests are now run on pending patches
     * https://netdev.bots.linux.dev/status.html
   * Not reporting back to patchwork, yet, because there’s a bunch of
     pre-existing failures
   * Paolo: we should extend the tests with mptcp tests
   * DSA tests may also be useful - Andrew to investigate if they can run in SW
   * We’re looking to integrate with other people running tests themselves


Unrelated to the call, but we have also posted a "2023 netdev
retrospective": https://people.kernel.org/kuba/netdev-in-2023