From: Saeed Mahameed <saeed@kernel.org>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
"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 12:19:20 -0700 [thread overview]
Message-ID: <aFRiuIPidlx7Qsy9@x130> (raw)
In-Reply-To: <d9bcc48d-17a2-4d12-bacd-6bef296b45c6@nvidia.com>
On 19 Jun 19:00, Mark Bloch wrote:
>
>
>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.
>
I think what Mark did here is fine, Yes I understand this is not
applicable to net-next yet, but the point is review and we can do the
following, when review is done:
I can Apply the mlx5-next portion to mlx5-next and Mark on V2 can send the
net-next stuff + A PR request to the mlx5-next branch, this is how we used
to do it all the time, but this time review happens all at once for both
trees.
Jakub is this acceptable ?
next prev parent reply other threads:[~2025-06-19 19:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 11:37 [PATCH net-next 0/5] net/mlx5e: Add support for PCIe congestion events 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
2025-06-19 19:19 ` Saeed Mahameed [this message]
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=aFRiuIPidlx7Qsy9@x130 \
--to=saeed@kernel.org \
--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=mbloch@nvidia.com \
--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 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.