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.

This series adds support for receiving and exposing such events as
ethtool counters.

2 new pairs of counters are exposed: pci_bw_in/outbound_high/low. These
should help the user understand if the device PCI is under pressure.
The thresholds are configurable via sysfs.

Dragos Tatulea (5):
  net/mlx5: Small refactor for general object capabilities
  net/mlx5: Add IFC bits for PCIe Congestion Event object
  net/mlx5e: Create/destroy PCIe Congestion Event object
  net/mlx5e: Add device PCIe congestion ethtool stats
  net/mlx5e: Make PCIe congestion event thresholds configurable

 .../ethernet/mellanox/mlx5/counters.rst       |  32 ++
 .../net/ethernet/mellanox/mlx5/core/Makefile  |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |   2 +
 .../mellanox/mlx5/core/en/pcie_cong_event.c   | 464 ++++++++++++++++++
 .../mellanox/mlx5/core/en/pcie_cong_event.h   |  11 +
 .../net/ethernet/mellanox/mlx5/core/en_main.c |   3 +
 .../ethernet/mellanox/mlx5/core/en_stats.c    |   1 +
 .../ethernet/mellanox/mlx5/core/en_stats.h    |   1 +
 drivers/net/ethernet/mellanox/mlx5/core/eq.c  |   4 +
 include/linux/mlx5/mlx5_ifc.h                 |  67 ++-
 10 files changed, 575 insertions(+), 12 deletions(-)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/pcie_cong_event.c
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/pcie_cong_event.h


base-commit: d3623dd5bd4e1fc9acfc08dd0064658bbbf1e8de
-- 
2.34.1

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.

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:

  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.

SMH

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

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 ? 

On Thu, 19 Jun 2025 12:19:20 -0700 Saeed Mahameed wrote:
> I think what Mark did here is fine, Yes I understand this is not
> applicable to net-next yet,

Yes, once again netdev is the problem.

> 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 ? 

Don't complicate it, please. Send a PR with the interface patches and
we can review the rest.

On Thu, Jun 19, 2025 at 02:37:16PM +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.

<...>

> Dragos Tatulea (5):
>   net/mlx5: Small refactor for general object capabilities
>   net/mlx5: Add IFC bits for PCIe Congestion Event object

Applied these patches to mlx5-next.

Thanks