kernel/drivers/net/ethernet/sfc/ethtool_common.c, branch linux-6.18.y

net: ethtool: move rxfh_fields callbacks under the rss_lock

2025-06-30T15:41:24Z

Netlink code will want to perform the RSS_SET operation atomically under the rss_lock. sfc wants to hold the rss_lock in rxfh_fields_get, which makes that difficult. Lets move the locking up to the core so that for all driver-facing callbacks rss_lock is taken consistently by the core. Link: https://patch.msgid.link/20250626202848.104457-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

eth: sfc: migrate to new RXFH callbacks

2025-06-21T14:53:39Z

Migrate to new callbacks added by commit 9bb00786fc61 ("net: ethtool: add dedicated callbacks for getting and setting rxfh fields"). This driver's RXFH config is read only / fixed so the conversion is purely factoring out the handling into a helper. One thing of note that this is one of the two drivers which pays attention to rss_context. Reviewed-by: Edward Cree Link: https://patch.msgid.link/20250618203823.1336156-4-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: sfc: use ethtool string helpers

2024-11-09T17:10:37Z

The latter is the preferred way to copy ethtool strings. Avoids manually incrementing the pointer. Cleans up the code quite well. Signed-off-by: Rosen Penev Acked-by: Edward Cree Link: https://patch.msgid.link/20241105231855.235894-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski

sfc: add n_rx_overlength to ethtool stats

2024-10-06T15:02:23Z

The previous patch changed when we increment the RX queue's rx_packets counter, to match the semantics of netdev per-queue stats. The differences between the old and new counts are scatter errors (which produce a WARN_ON) and this counter, which is incremented by efx_rx_packet__check_len() when an RX packet (which was placed in a single buffer by SG, i.e. n_frags == 1) has a length (from the RX event) which is too long to fit in the RX buffer. If this occurs, we drop the packet and fire a ratelimited netif_err(). The counter previously was not reported anywhere; add it to ethtool -S output to ensure users still have this information. Reviewed-by: Jacob Keller Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: remove obsolete counters from struct efx_channel

2024-10-06T15:02:22Z

The n_rx_tobe_disc and n_rx_mcast_mismatch counters are a legacy from farch, and are never written in EF10 or EF100 code. Remove them from the struct and from ethtool -S output, saving a bit of memory and avoiding user confusion. Reviewed-by: Jacob Keller Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: remove get_rxfh_context dead code

2024-06-29T01:53:21Z

The core now always satisfies 'ethtool -x context nonzero' from its own tracking, so our lookup code for that case is never called. Remove it. Signed-off-by: Edward Cree Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/b426fcc416dedc8f203e52eebef6891eccebe4c1.1719502240.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski

sfc: use new rxfh_context API

2024-06-29T01:53:21Z

The core is now responsible for allocating IDs and a memory region for us to store our state (struct efx_rss_context_priv), so we no longer need efx_alloc_rss_context_entry() and friends. Since the contexts are now maintained by the core, use the core's lock (net_dev->ethtool->rss_lock), rather than our own mutex (efx->rss_lock), to serialise access against changes; and remove the now-unused efx->rss_lock from struct efx_nic. Signed-off-by: Edward Cree Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/150274740ea8cc137fef5502541ce573d32fb319.1719502240.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski

net: ethtool: get rid of get/set_rxfh_context functions

2023-12-14T06:07:16Z

Add the RSS context parameters to struct ethtool_rxfh_param and use the get/set_rxfh to handle the RSS contexts as well. This is part 2/2 of the fix suggested in [1]: - Add a rss_context member to the argument struct and a capability like cap_link_lanes_supported to indicate whether driver supports rss contexts, then you can remove *et_rxfh_context functions, and instead call *et_rxfh() with a non-zero rss_context. Link: https://lore.kernel.org/netdev/20231121152906.2dd5f487@kernel.org/ [1] CC: Jesse Brandeburg CC: Tony Nguyen CC: Marcin Wojtas CC: Russell King CC: Sunil Goutham CC: Geetha sowjanya CC: Subbaraya Sundeep CC: hariprasad CC: Saeed Mahameed CC: Leon Romanovsky CC: Edward Cree CC: Martin Habets Suggested-by: Jakub Kicinski Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20231213003321.605376-3-ahmed.zaki@intel.com Signed-off-by: Jakub Kicinski

net: ethtool: pass a pointer to parameters to get/set_rxfh ethtool ops

2023-12-14T06:07:16Z

The get/set_rxfh ethtool ops currently takes the rxfh (RSS) parameters as direct function arguments. This will force us to change the API (and all drivers' functions) every time some new parameters are added. This is part 1/2 of the fix, as suggested in [1]: - First simplify the code by always providing a pointer to all params (indir, key and func); the fact that some of them may be NULL seems like a weird historic thing or a premature optimization. It will simplify the drivers if all pointers are always present. - Then make the functions take a dev pointer, and a pointer to a single struct wrapping all arguments. The set_* should also take an extack. Link: https://lore.kernel.org/netdev/20231121152906.2dd5f487@kernel.org/ [1] Suggested-by: Jakub Kicinski Suggested-by: Jacob Keller Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20231213003321.605376-2-ahmed.zaki@intel.com Signed-off-by: Jakub Kicinski

sfc: remove 'log-tc-errors' ethtool private flag

2022-10-19T20:00:05Z

It no longer does anything now that we're using formatted extacks instead. So we can remove the driver's whole get/set priv_flags implementation. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski