Commit 84eaf4359c36 ("net: ethtool: add get_rx_ring_count callback to
optimize RX ring queries") added specific support for GRXRINGS callback,
simplifying .get_rxnfc.
Remove the handling of GRXRINGS in .get_rxnfc() by moving it to the new
.get_rx_ring_count().
This simplifies the RX ring count retrieval and aligns the following
drivers with the new ethtool API for querying RX ring parameters.
* emulex/benet
* engleder/tsnep
* mediatek
* amazon/ena
* microchip/lan743x
* amd/xgbe
* chelsio/cxgb4
* wangxun/txgbe
* cadence/macb
Part 1 is already merged in net-next and can be seen in
https://lore.kernel.org/all/20260109-grxring_big_v1-v1-0-a0f77f732006@debian.org/
PS: all of these change were compile-tested only.
---
Breno Leitao (9):
net: benet: convert to use .get_rx_ring_count
net: tsnep: convert to use .get_rx_ring_count
net: mediatek: convert to use .get_rx_ring_count
net: ena: convert to use .get_rx_ring_count
net: lan743x: convert to use .get_rx_ring_count
net: xgbe: convert to use .get_rx_ring_count
net: cxgb4: convert to use .get_rx_ring_count
net: macb: convert to use .get_rx_ring_count
net: txgbe: convert to use .get_rx_ring_count
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 22 +++------------
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 15 +++--------
drivers/net/ethernet/cadence/macb_main.c | 11 +++++---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c | 11 +++++---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 31 ++++++----------------
drivers/net/ethernet/engleder/tsnep_ethtool.c | 11 +++++---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 ++++++-----
drivers/net/ethernet/microchip/lan743x_ethtool.c | 13 +++------
drivers/net/ethernet/wangxun/txgbe/txgbe_ethtool.c | 12 ++++++---
9 files changed, 58 insertions(+), 83 deletions(-)
---
base-commit: cc75d43783f74fe0a1c288aba9e6ac55f1444977
change-id: 20260115-grxring_big_v2-eed9a5803431
Best regards,
--
Breno Leitao [off-list ref]
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by be_get_rxnfc(),
remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/emulex/benet/be_ethtool.c | 31 +++++++-------------------
1 file changed, 8 insertions(+), 23 deletions(-)
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only useful command handled by
ena_get_rxnfc(), remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/amazon/ena/ena_ethtool.c | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
@@ -835,27 +835,11 @@ static int ena_set_rxfh_fields(struct net_device *netdev,returnena_com_fill_hash_ctrl(ena_dev,proto,hash_fields);}-staticintena_get_rxnfc(structnet_device*netdev,structethtool_rxnfc*info,-u32*rules)+staticu32ena_get_rx_ring_count(structnet_device*netdev){structena_adapter*adapter=netdev_priv(netdev);-intrc=0;-switch(info->cmd){-caseETHTOOL_GRXRINGS:-info->data=adapter->num_io_queues;-rc=0;-break;-caseETHTOOL_GRXCLSRLCNT:-caseETHTOOL_GRXCLSRULE:-caseETHTOOL_GRXCLSRLALL:-default:-netif_err(adapter,drv,netdev,-"Command parameter %d is not supported\n",info->cmd);-rc=-EOPNOTSUPP;-}--returnrc;+returnadapter->num_io_queues;}staticu32ena_get_rxfh_indir_size(structnet_device*netdev)
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by
lan743x_ethtool_get_rxnfc(), remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/microchip/lan743x_ethtool.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by xgbe_get_rxnfc(),
remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
-----Original Message-----
From: Breno Leitao <leitao@debian.org>
Sent: Thursday, January 15, 2026 6:38 AM
Subject: [EXTERNAL] [PATCH net-next 4/9] net: ena: convert to use
.get_rx_ring_count
Use the newly introduced .get_rx_ring_count ethtool ops callback instead of
handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only useful command handled by
ena_get_rxnfc(), remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Thank you for submitting this patch
Reviewed-by: Arthur Kiyanovski <akiyano@amazon.com>
I think we need to add this check to set_rxfh now. The error coming
from get_rxnfc/GRXRINGS effectively shielded the driver from set_rxfh
calls ever happening when there's only 1 ring. Now they will happen.
Applied the rest
I think we need to add this check to set_rxfh now. The error coming
from get_rxnfc/GRXRINGS effectively shielded the driver from set_rxfh
calls ever happening when there's only 1 ring. Now they will happen.
You are absolutely correct. The ethtool core calls
get_rxnfc(ETHTOOL_GRXRINGS) _before_ allowing RSS configuration via
set_rxfh, and if it fails, ethtool_set_rxfh() will fail as well. And
with the current change, ethtool_set_rxfh() will not fail if the adapter
is not multi-queue.
Thanks for the heads-up. I will send a v2 shortly.
--breno
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Since ETHTOOL_GRXRINGS was the only command handled by xgbe_get_rxnfc(),
remove the function entirely.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
I think we need to add this check to set_rxfh now. The error coming
from get_rxnfc/GRXRINGS effectively shielded the driver from set_rxfh
calls ever happening when there's only 1 ring. Now they will happen.
You are absolutely correct. The ethtool core calls
get_rxnfc(ETHTOOL_GRXRINGS) _before_ allowing RSS configuration via
set_rxfh, and if it fails, ethtool_set_rxfh() will fail as well. And
with the current change, ethtool_set_rxfh() will not fail if the adapter
is not multi-queue.
Upon further consideration, should we implement this limitation directly within
the ethtool infrastructure?
Something as:
Author: Breno Leitao [off-list ref]
Date: Mon Jan 19 03:25:05 2026 -0800
ethtool: reject RSS configuration on single-queue devices
Configuring RSS (Receive Side Scaling) makes no sense when the device
only has a single RX queue - there is nothing to distribute traffic
across. The indirection table would just map everything to queue 0.
Add explicit checks in ethtool_set_rxfh_indir() and ethtool_set_rxfh()
to reject RSS configuration when the device reports fewer than 2 RX rings.
This protects all drivers uniformly at the core level.
Signed-off-by: Breno Leitao [off-list ref]
From: Nicolas Ferre <nicolas.ferre@microchip.com> Date: 2026-01-19 13:09:31
On 15/01/2026 at 15:37, Breno Leitao wrote:
Use the newly introduced .get_rx_ring_count ethtool ops callback instead
of handling ETHTOOL_GRXRINGS directly in .get_rxnfc().
Signed-off-by: Breno Leitao <leitao@debian.org>
Looks good to me:
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Thanks, best regards,
Nicolas
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski [off-list ref]:
On Thu, 15 Jan 2026 06:37:47 -0800 you wrote:
Commit 84eaf4359c36 ("net: ethtool: add get_rx_ring_count callback to
optimize RX ring queries") added specific support for GRXRINGS callback,
simplifying .get_rxnfc.
Remove the handling of GRXRINGS in .get_rxnfc() by moving it to the new
.get_rx_ring_count().
[...]
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-01-19 17:45:17
On Mon, 19 Jan 2026 04:56:49 -0800 Breno Leitao wrote:
quoted
quoted
I think we need to add this check to set_rxfh now. The error coming
from get_rxnfc/GRXRINGS effectively shielded the driver from set_rxfh
calls ever happening when there's only 1 ring. Now they will happen.
You are absolutely correct. The ethtool core calls
get_rxnfc(ETHTOOL_GRXRINGS) _before_ allowing RSS configuration via
set_rxfh, and if it fails, ethtool_set_rxfh() will fail as well. And
with the current change, ethtool_set_rxfh() will not fail if the adapter
is not multi-queue.
Upon further consideration, should we implement this limitation directly within
the ethtool infrastructure?
That may cause some regressions, we're getting the number of currently
configured Rx rings. If we were to check how many Rx rings the device
has that'd make sense. But since we can only access currently
configured rings, in theory, if the device has multiple rings,
just only one is active now - changing config for the RSS key or
function should work just fine. IOW
# change key
# increase ring count to make they key meaningful
Used to work.