From: Petr Machata <petrm@nvidia.com>
To: Keno Fischer <keno@juliahub.com>
Cc: <netdev@vger.kernel.org>, Ido Schimmel <idosch@nvidia.com>,
Petr Machata <petrm@nvidia.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] mlxsw: spectrum_ethtool: expose per-PG rx_discards
Date: Mon, 18 May 2026 19:19:47 +0200 [thread overview]
Message-ID: <87mrxwmxmy.fsf@nvidia.com> (raw)
In-Reply-To: <agqkMwgM1PdkyMUR@juliahub.com>
Keno Fischer <keno@juliahub.com> writes:
> PPCNT group 0x10 (per-priority counters) carries an rx_discards field at
> offset 0x78. These counters aggregate up into if_in_discards, but don't
> show up anywhere else. Since there are many things that aggregate into
> `if_in_discards`, having these counters helps distinguish what caused
> those discards (in my case they were caused by headroom buffer overruns
> due to inappropriately configured buffer sizes).
>
> Of note, from emperical testing, these counter are per-"priority group"
> (PG) not per-"switch priority". It's a bit confusing, because the rest
> of these counter are per-"switch priority" and the header file calls
> these "Per Priority Group Counters". However, that should be read as
> "(Per Priority) Group Counters", not "Per (Priority Group) Counters".
I think it's (Per-Priority Group) Counters. As in group of counters that
are per priority. Similarly there's the "Ethernet Discard Counter Group
Counters". These names come from the HW manual.
> I attempted to distinguish this in the counter naming by calling these
> `rx_discards_pg_N` rather than `rx_discards_prio_N` (which is the
> naming scheme of the other counters in this PPCNT group).
>
> I will also note that the mlx5 driver (which already has this counter)
> uses the schme `rx_prioN_discards` (and same for the other counters
> in this group). However, I was unable to determine whether the mlx5
> counters behave the same as the mlxsw counters with respect to PG
> mapping. An attempt to remap to a different PG there did not change
> which counter incremented, but the mlx5 configuration code is quite
> different, so it's possible the remapping needs to be done differently.
>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Keno Fischer <keno@juliahub.com>
LGTM, thanks!
Reviewed-by: Petr Machata <petrm@nvidia.com>
next prev parent reply other threads:[~2026-05-18 17:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 5:31 [PATCH net-next] mlxsw: spectrum_ethtool: expose per-PG rx_discards Keno Fischer
2026-05-18 17:19 ` Petr Machata [this message]
2026-05-19 22:50 ` Keno Fischer
2026-05-21 0:20 ` patchwork-bot+netdevbpf
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=87mrxwmxmy.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=idosch@nvidia.com \
--cc=keno@juliahub.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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.