From: Mark Bloch <mbloch@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Simon Horman <horms@kernel.org>,
saeedm@nvidia.com, gal@nvidia.com, leonro@nvidia.com,
tariqt@nvidia.com, Leon Romanovsky <leon@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion events
Date: Thu, 19 Jun 2025 19:00:45 +0300 [thread overview]
Message-ID: <d9bcc48d-17a2-4d12-bacd-6bef296b45c6@nvidia.com> (raw)
In-Reply-To: <20250619075543.1d31f937@kernel.org>
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
next prev parent reply other threads:[~2025-06-19 16:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 11:37 Mark Bloch
2025-06-19 11:37 ` [PATCH mlx5-next 1/5] net/mlx5: Small refactor for general object capabilities Mark Bloch
2025-06-19 11:37 ` [PATCH mlx5-next 2/5] net/mlx5: Add IFC bits for PCIe Congestion Event object Mark Bloch
2025-06-19 11:37 ` [PATCH net-next 3/5] net/mlx5e: Create/destroy " Mark Bloch
2025-06-19 11:37 ` [PATCH net-next 4/5] net/mlx5e: Add device PCIe congestion ethtool stats Mark Bloch
2025-06-19 11:37 ` [PATCH net-next 5/5] net/mlx5e: Make PCIe congestion event thresholds configurable Mark Bloch
2025-06-19 14:55 ` [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion events Jakub Kicinski
2025-06-19 16:00 ` Mark Bloch [this message]
2025-06-19 19:19 ` Saeed Mahameed
2025-06-19 22:22 ` Jakub Kicinski
2025-06-25 11:37 ` Leon Romanovsky
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=d9bcc48d-17a2-4d12-bacd-6bef296b45c6@nvidia.com \
--to=mbloch@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®