Commit ecdff893 authored by Gal Pressman's avatar Gal Pressman Committed by Jakub Kicinski
Browse files

ethtool: Symmetric OR-XOR RSS hash 



Add an additional type of symmetric RSS hash type: OR-XOR.
The "Symmetric-OR-XOR" algorithm transforms the input as follows:

(SRC_IP | DST_IP, SRC_IP ^ DST_IP, SRC_PORT | DST_PORT, SRC_PORT ^ DST_PORT)

Change 'cap_rss_sym_xor_supported' to 'supported_input_xfrm', a bitmap
of supported RXH_XFRM_* types.

Reviewed-by: default avatarCosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
Signed-off-by: default avatarGal Pressman <gal@nvidia.com>
Reviewed-by: default avatarEdward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20250224174416.499070-2-gal@nvidia.com


Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parent ad530283

Documentation/networking/ethtool-netlink.rst

+1 −1
Original line number Diff line number Diff line
@@ -1934,7 +1934,7 @@ ETHTOOL_A_RSS_INDIR attribute returns RSS indirection table where each byte 
indicates queue number.

ETHTOOL_A_RSS_INPUT_XFRM attribute is a bitmap indicating the type of

transformation applied to the input protocol fields before given to the RSS

hfunc. Current supported option is symmetric-xor.

hfunc. Current supported options are symmetric-xor and symmetric-or-xor.



PLCA_GET_CFG

============

Documentation/networking/scaling.rst

+11 −4
Original line number Diff line number Diff line
@@ -49,14 +49,21 @@ destination address) and TCP/UDP (source port, destination port) tuples 
are swapped, the computed hash is the same. This is beneficial in some

applications that monitor TCP/IP flows (IDS, firewalls, ...etc) and need

both directions of the flow to land on the same Rx queue (and CPU). The

"Symmetric-XOR" is a type of RSS algorithms that achieves this hash

symmetry by XORing the input source and destination fields of the IP

and/or L4 protocols. This, however, results in reduced input entropy and

could potentially be exploited. Specifically, the algorithm XORs the input

"Symmetric-XOR" and "Symmetric-OR-XOR" are types of RSS algorithms that

achieve this hash symmetry by XOR/ORing the input source and destination

fields of the IP and/or L4 protocols. This, however, results in reduced

input entropy and could potentially be exploited.



Specifically, the "Symmetric-XOR" algorithm XORs the input

as follows::



    # (SRC_IP ^ DST_IP, SRC_IP ^ DST_IP, SRC_PORT ^ DST_PORT, SRC_PORT ^ DST_PORT)



The "Symmetric-OR-XOR" algorithm, on the other hand, transforms the input as

follows::



    # (SRC_IP | DST_IP, SRC_IP ^ DST_IP, SRC_PORT | DST_PORT, SRC_PORT ^ DST_PORT)



The result is then fed to the underlying RSS algorithm.



Some advanced NICs allow steering packets to queues based on

drivers/net/ethernet/intel/iavf/iavf_ethtool.c

+1 −1
Original line number Diff line number Diff line
@@ -1808,7 +1808,7 @@ static int iavf_set_rxfh(struct net_device *netdev, 
static const struct ethtool_ops iavf_ethtool_ops = {

	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |

				     ETHTOOL_COALESCE_USE_ADAPTIVE,

	.cap_rss_sym_xor_supported = true,

	.supported_input_xfrm	= RXH_XFRM_SYM_XOR,

	.get_drvinfo		= iavf_get_drvinfo,

	.get_link		= ethtool_op_get_link,

	.get_ringparam		= iavf_get_ringparam,

drivers/net/ethernet/intel/ice/ice_ethtool.c

+1 −1
Original line number Diff line number Diff line
@@ -4770,7 +4770,7 @@ static const struct ethtool_ops ice_ethtool_ops = { 
	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |

				     ETHTOOL_COALESCE_USE_ADAPTIVE |

				     ETHTOOL_COALESCE_RX_USECS_HIGH,

	.cap_rss_sym_xor_supported = true,

	.supported_input_xfrm	= RXH_XFRM_SYM_XOR,

	.rxfh_per_ctx_key	= true,

	.get_link_ksettings	= ice_get_link_ksettings,

	.set_link_ksettings	= ice_set_link_ksettings,

include/linux/ethtool.h

+2 −3
Original line number Diff line number Diff line
@@ -763,13 +763,12 @@ struct kernel_ethtool_ts_info { 


/**

 * struct ethtool_ops - optional netdev operations

 * @supported_input_xfrm: supported types of input xfrm from %RXH_XFRM_*.

 * @cap_link_lanes_supported: indicates if the driver supports lanes

 *	parameter.

 * @cap_rss_ctx_supported: indicates if the driver supports RSS

 *	contexts via legacy API, drivers implementing @create_rxfh_context

 *	do not have to set this bit.

 * @cap_rss_sym_xor_supported: indicates if the driver supports symmetric-xor

 *	RSS.

 * @rxfh_per_ctx_key: device supports setting different RSS key for each

 *	additional context. Netlink API should report hfunc, key, and input_xfrm

 *	for every context, not just context 0.
@@ -995,9 +994,9 @@ struct kernel_ethtool_ts_info { 
 * of the generic netdev features interface.

 */

struct ethtool_ops {

	u32     supported_input_xfrm:8;

	u32     cap_link_lanes_supported:1;

	u32     cap_rss_ctx_supported:1;

	u32	cap_rss_sym_xor_supported:1;

	u32	rxfh_per_ctx_key:1;

	u32	cap_rss_rxnfc_adds:1;

	u32	rxfh_indir_space;