netdev - Re: [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion events

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <d9bcc48d-17a2-4d12-bacd-6bef296b45c6@nvidia.com>
Date: Thu, 19 Jun 2025 19:00:45 +0300
From: Mark Bloch <mbloch@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 Simon Horman <horms@...nel.org>, saeedm@...dia.com, gal@...dia.com,
 leonro@...dia.com, tariqt@...dia.com, Leon Romanovsky <leon@...nel.org>,
 Jonathan Corbet <corbet@....net>, netdev@...r.kernel.org,
 linux-rdma@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion
 events

On 19/06/2025 17:55, Jakub Kicinski wrote:
> On Thu, 19 Jun 2025 14:37:16 +0300 Mark Bloch wrote:
>> PCIe congestion events are events generated by the firmware when the
>> device side has sustained PCIe inbound or outbound traffic above
>> certain thresholds. The high and low threshold are hysteresis thresholds
>> to prevent flapping: once the high threshold has been reached, a low
>> threshold event will be triggered only after the bandwidth usage went
>> below the low threshold.
> 
> What are we supposed to do with a series half of which is tagged for
> one tree and half for another? If you want for some of the patches to
> go via the shared tree - you have to post them separately.
> Ideally you'd post them to the list in a combined "pull request +
> patches" format (see for example how Marc posts CAN patches, or Pablo
> posts netfilter). Once we pull that you can sent the net-next stuff
> separately as patches.

Miscommunication about the proper process, thanks for the explanation.
PR + patches seems cleaner and provides more context,
so I’ll go with that.

> 
> I feel like I just had the same exact conversation with Tariq recently.
> Really not great when same process explainer has to be given to
> multiple people from the same company :( I'd like to remind y'all that
> reading the mailing list is not optional:

I do follow the mailing list and double checked what should be done in
this scenario. In the end it's my responsibility so it's my fault.

> 
>   Mailing list participation
>   --------------------------
>   
>   Linux kernel uses mailing lists as the primary form of communication.
>   Maintainers must be subscribed and follow the appropriate subsystem-wide
>   mailing list. Either by subscribing to the whole list or using more
>   modern, selective setup like
>   `lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_.
>   
> See: https://www.kernel.org/doc/html/next/maintainer/feature-and-driver-maintainers.html#mailing-list-participation
> 
> Then again, I guess you're not a maintainer. There are 2 maintainers
> for the driver listed and yet we get patches from a 3rd unlisted person.

Tariq is on vacation which got extended because of flight issues.
I've mentioned I'll be handling the mlx5 submissionד until his return
on v3 of the tcp zero-copy series.

> 
> SMH