On 29/03/2023 10.10, Edward Cree wrote:
On 28/03/2023 21:15, Jesper Dangaard Brouer wrote:
Hardware RSS types are differently encoded for each hardware NIC. Most
hardware represent RSS hash type as a number. Determining L3 vs L4 often
requires a mapping table as there often isn't a pattern or sorting
according to ISO layer.
The patch introduce a XDP RSS hash type (xdp_rss_hash_type) that can both
be seen as a number that is ordered according by ISO layer, and can be bit
masked to separate IPv4 and IPv6 types for L4 protocols. Room is available
for extending later while keeping these properties. This maps and unifies
difference to hardware specific hashes.
Would it be better to make use of the ETHTOOL_GRXFH defines (stuff
like UDP_V6_FLOW, RXH_L4_B_0_1 etc.)? Seems like that could allow
for some code reuse in drivers.
Thanks for the point to ethtool defines.
I can see that these are used when configuring the hardware RSS hash the
NIC should calculate.
From: include/uapi/linux/ethtool.h
/* L3-L4 network traffic flow hash options */
#define RXH_L2DA (1 << 1)
#define RXH_VLAN (1 << 2)
#define RXH_L3_PROTO (1 << 3)
#define RXH_IP_SRC (1 << 4)
#define RXH_IP_DST (1 << 5)
#define RXH_L4_B_0_1 (1 << 6) /* src port in case of TCP/UDP/SCTP */
#define RXH_L4_B_2_3 (1 << 7) /* dst port in case of TCP/UDP/SCTP */
#define RXH_DISCARD (1 << 31)
I notice that I forgot about VLAN tag (RXH_VLAN) also can be part of the
hash calc in my proposed design.
It is interpreting to follow the possible ethool cmd->flow_type's:
/* L2-L4 network traffic flow types */
#define TCP_V4_FLOW 0x01 /* hash or spec (tcp_ip4_spec) */
#define UDP_V4_FLOW 0x02 /* hash or spec (udp_ip4_spec) */
#define SCTP_V4_FLOW 0x03 /* hash or spec (sctp_ip4_spec) */
#define AH_ESP_V4_FLOW 0x04 /* hash only */
#define TCP_V6_FLOW 0x05 /* hash or spec (tcp_ip6_spec; nfc only) */
#define UDP_V6_FLOW 0x06 /* hash or spec (udp_ip6_spec; nfc only) */
#define SCTP_V6_FLOW 0x07 /* hash or spec (sctp_ip6_spec; nfc only) */
#define AH_ESP_V6_FLOW 0x08 /* hash only */
#define AH_V4_FLOW 0x09 /* hash or spec (ah_ip4_spec) */
#define ESP_V4_FLOW 0x0a /* hash or spec (esp_ip4_spec) */
#define AH_V6_FLOW 0x0b /* hash or spec (ah_ip6_spec; nfc only) */
#define ESP_V6_FLOW 0x0c /* hash or spec (esp_ip6_spec; nfc only) */
#define IPV4_USER_FLOW 0x0d /* spec only (usr_ip4_spec) */
#define IP_USER_FLOW IPV4_USER_FLOW
#define IPV6_USER_FLOW 0x0e /* spec only (usr_ip6_spec; nfc only) */
#define IPV4_FLOW 0x10 /* hash only */
#define IPV6_FLOW 0x11 /* hash only */
#define ETHER_FLOW 0x12 /* spec only (ether_spec) */
/* Flag to enable additional fields in struct ethtool_rx_flow_spec */
#define FLOW_EXT 0x80000000
#define FLOW_MAC_EXT 0x40000000
/* Flag to enable RSS spreading of traffic matching rule (nfc only) */
#define FLOW_RSS 0x20000000
It is clear that we need to support TCP+UDP+SCTP.
I assume the IPSEC is AH (Authentication Header) and ESP ( Encapsulating
Security Payload. Thus, (like I found with mlx5) we also need IPSET and
maybe a bit (or number) for each protocol AH or ESP.
Both ah_ip4_spec and esp_ip4_spec points to ethtool.h struct:
/**
* struct ethtool_ah_espip4_spec - flow specification for IPsec/IPv4
* @ip4src: Source host
* @ip4dst: Destination host
* @spi: Security parameters index
* @tos: Type-of-service
*
* This can be used to specify an IPsec transport or tunnel over IPv4.
*/
struct ethtool_ah_espip4_spec {
__be32 ip4src;
__be32 ip4dst;
__be32 spi;
__u8 tos;
};
Which confirms that it is the SPI that is the extra part of the hash.
--Jesper
