netdev - Re: [PATCH net] net/mlx5: Fill out devlink dev info only for PFs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3faf95ef-022a-412e-879d-c6a326f4267a@gmail.com>
Date: Thu, 6 Mar 2025 22:12:52 +0200
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 saeedm@...dia.com, leon@...nel.org, tariqt@...dia.com,
 andrew+netdev@...n.ch, Gal Pressman <gal@...dia.com>
Subject: Re: [PATCH net] net/mlx5: Fill out devlink dev info only for PFs



On 06/03/2025 21:39, Jakub Kicinski wrote:
> On Thu, 6 Mar 2025 21:20:58 +0200 Tariq Toukan wrote:
>> On 06/03/2025 4:30, Jakub Kicinski wrote:
>>> On Wed, 5 Mar 2025 20:55:15 +0200 Tariq Toukan wrote:
>>>> Reviewed-by: Tariq Toukan <tariqt@...dia.com>
>>>
>>> Too late, take it via your tree, please.
>>> You need to respond within 24h or take the patches.
>>
>> Never heard of a 24h rule. Not clear to me what rule you're talking
>> about, what's the rationale behind it, and where it's coming from.
>>
>> It's pretty obvious for everyone that responding within 24h cannot be
>> committed, and is not always achievable.
>>
>> Moreover, this contradicts with maintainer-netdev.rst, which explicitly
>> aligns the expected review timeline to be 48h for triage, also to give
>> the opportunity for more reviewers to share their thoughts.
> 
> Quoting documentation:
> 

Thanks for the pointer.

>    Responsibilities
>    ================
>    
>    The amount of maintenance work is usually proportional to the size
>    and popularity of the code base. Small features and drivers should
>    require relatively small amount of care and feeding. Nonetheless
>    when the work does arrive (in form of patches which need review,
>    user bug reports etc.) it has to be acted upon promptly.
>    Even when a particular driver only sees one patch a month, or a quarter,
>    a subsystem could well have a hundred such drivers. Subsystem
>    maintainers cannot afford to wait a long time to hear from reviewers.
>    
>    The exact expectations on the response time will vary by subsystem.
>    The patch review SLA the subsystem had set for itself can sometimes
>    be found in the subsystem documentation. Failing that as a rule of thumb
>    reviewers should try to respond quicker than what is the usual patch
>    review delay of the subsystem maintainer. The resulting expectations
>    may range from two working days for fast-paced subsystems (e.g. networking)

So no less than two working days for any subsystem.
Okay, now this makes more sense.

>    to as long as a few weeks in slower moving parts of the kernel.
>    
> See: https://www.kernel.org/doc/html/next/maintainer/feature-and-driver-maintainers.html#responsibilities