Re: [xdp-hints] Re: [PATCH bpf RFC 1/4] xdp: rss hash types representation

Jesper Dangaard Brouer
2023-03-29T12:13:58Z

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