From: Jakub Kicinski <kuba@kernel.org>
To: Carolina Jubran <cjubran@nvidia.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Andrew Lunn <andrew@lunn.ch>,
Michael Chan <michael.chan@broadcom.com>,
Pavan Chebbi <pavan.chebbi@broadcom.com>,
Tariq Toukan <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
intel-wired-lan@lists.osuosl.org,
Donald Hunter <donald.hunter@gmail.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, Yael Chemla <ychemla@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next v3 3/4] net/mlx5e: Add logic to read RS-FEC histogram bin ranges from PPHCR
Date: Thu, 18 Sep 2025 15:18:45 -0700 [thread overview]
Message-ID: <20250918151845.32a90e3e@kernel.org> (raw)
In-Reply-To: <f84efe86-098f-4783-85af-4289f62804e9@nvidia.com>
On Thu, 18 Sep 2025 22:41:38 +0300 Carolina Jubran wrote:
> On 18/09/2025 18:40, Jakub Kicinski wrote:
> > I understand that the modes should not be exposed.
> > I don't get why this has anything to do with the number of bins.
> > Does the FW hardcode that the non-Ethernet modes use bins >=16?
> > When you say "internal modes that can report more than 16 bins"
> > it sounds like it uses bins starting from 0, e.g. 0..31.
>
> The FW hardcodes that Ethernet modes report up to 16 bins,
> while non-Ethernet modes may report up to 19.
> And yes, those modes use bins starting from 0, e.g. 0..18.
Which means that the number of bins doesn't really matter.
You're purely using the bin count as a second order check
to catch the device being in the wrong mode (and I presume
you think that device in the wrong mode should never enter
the function given the WARN_ON_ONCE()).
Please check the mode directly or remove the check completely.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Carolina Jubran <cjubran@nvidia.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Andrew Lunn <andrew@lunn.ch>,
Michael Chan <michael.chan@broadcom.com>,
Pavan Chebbi <pavan.chebbi@broadcom.com>,
Tariq Toukan <tariqt@nvidia.com>, Gal Pressman <gal@nvidia.com>,
intel-wired-lan@lists.osuosl.org,
Donald Hunter <donald.hunter@gmail.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, Yael Chemla <ychemla@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [PATCH net-next v3 3/4] net/mlx5e: Add logic to read RS-FEC histogram bin ranges from PPHCR
Date: Thu, 18 Sep 2025 15:18:45 -0700 [thread overview]
Message-ID: <20250918151845.32a90e3e@kernel.org> (raw)
In-Reply-To: <f84efe86-098f-4783-85af-4289f62804e9@nvidia.com>
On Thu, 18 Sep 2025 22:41:38 +0300 Carolina Jubran wrote:
> On 18/09/2025 18:40, Jakub Kicinski wrote:
> > I understand that the modes should not be exposed.
> > I don't get why this has anything to do with the number of bins.
> > Does the FW hardcode that the non-Ethernet modes use bins >=16?
> > When you say "internal modes that can report more than 16 bins"
> > it sounds like it uses bins starting from 0, e.g. 0..31.
>
> The FW hardcodes that Ethernet modes report up to 16 bins,
> while non-Ethernet modes may report up to 19.
> And yes, those modes use bins starting from 0, e.g. 0..18.
Which means that the number of bins doesn't really matter.
You're purely using the bin count as a second order check
to catch the device being in the wrong mode (and I presume
you think that device in the wrong mode should never enter
the function given the WARN_ON_ONCE()).
Please check the mode directly or remove the check completely.
next prev parent reply other threads:[~2025-09-18 22:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 19:12 [Intel-wired-lan] [PATCH net-next v3 0/4] add FEC bins histogram report via ethtool Vadim Fedorenko
2025-09-16 19:12 ` Vadim Fedorenko
2025-09-16 19:12 ` [Intel-wired-lan] [PATCH net-next v3 1/4] ethtool: add FEC bins histogram report Vadim Fedorenko
2025-09-16 19:12 ` Vadim Fedorenko
2025-09-17 11:27 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-17 11:27 ` Loktionov, Aleksandr
2025-09-18 10:58 ` Vadim Fedorenko
2025-09-19 15:47 ` Tony Nguyen
2025-09-18 0:41 ` Jakub Kicinski
2025-09-18 0:41 ` Jakub Kicinski
2025-09-18 10:53 ` [Intel-wired-lan] " Vadim Fedorenko
2025-09-18 10:53 ` Vadim Fedorenko
2025-09-18 13:59 ` [Intel-wired-lan] " Jakub Kicinski
2025-09-18 13:59 ` Jakub Kicinski
2025-09-16 19:12 ` [Intel-wired-lan] [PATCH net-next v3 2/4] net/mlx5e: Don't query FEC statistics when FEC is disabled Vadim Fedorenko
2025-09-16 19:12 ` Vadim Fedorenko
2025-09-17 11:26 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-17 11:26 ` Loktionov, Aleksandr
2025-09-16 19:12 ` [Intel-wired-lan] [PATCH net-next v3 3/4] net/mlx5e: Add logic to read RS-FEC histogram bin ranges from PPHCR Vadim Fedorenko
2025-09-16 19:12 ` Vadim Fedorenko
2025-09-17 11:25 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-17 11:25 ` Loktionov, Aleksandr
2025-09-18 0:46 ` Jakub Kicinski
2025-09-18 0:46 ` Jakub Kicinski
2025-09-18 14:25 ` [Intel-wired-lan] " Carolina Jubran
2025-09-18 14:25 ` Carolina Jubran
2025-09-18 14:35 ` [Intel-wired-lan] " Jakub Kicinski
2025-09-18 14:35 ` Jakub Kicinski
2025-09-18 15:16 ` [Intel-wired-lan] " Carolina Jubran
2025-09-18 15:16 ` Carolina Jubran
2025-09-18 15:40 ` [Intel-wired-lan] " Jakub Kicinski
2025-09-18 15:40 ` Jakub Kicinski
2025-09-18 19:41 ` [Intel-wired-lan] " Carolina Jubran
2025-09-18 19:41 ` Carolina Jubran
2025-09-18 22:18 ` Jakub Kicinski [this message]
2025-09-18 22:18 ` Jakub Kicinski
2025-09-19 9:35 ` [Intel-wired-lan] " Carolina Jubran
2025-09-19 9:35 ` Carolina Jubran
2025-09-16 19:12 ` [Intel-wired-lan] [PATCH net-next v3 4/4] net/mlx5e: Report RS-FEC histogram statistics via ethtool Vadim Fedorenko
2025-09-16 19:12 ` Vadim Fedorenko
2025-09-17 11:24 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-17 11:24 ` Loktionov, Aleksandr
2025-09-18 0:48 ` Jakub Kicinski
2025-09-18 0:48 ` Jakub Kicinski
2025-09-18 14:32 ` [Intel-wired-lan] " Vadim Fedorenko
2025-09-18 14:32 ` Vadim Fedorenko
2025-09-18 14:40 ` [Intel-wired-lan] " Jakub Kicinski
2025-09-18 14:40 ` Jakub Kicinski
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=20250918151845.32a90e3e@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=cjubran@nvidia.com \
--cc=donald.hunter@gmail.com \
--cc=dtatulea@nvidia.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=tariqt@nvidia.com \
--cc=vadim.fedorenko@linux.dev \
--cc=ychemla@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.