[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <00b2e31a-4ec6-12fa-a428-38282cafbc58@redhat.com>
Date: Wed, 29 Mar 2023 14:13:07 +0200
From: Jesper Dangaard Brouer <jbrouer@...hat.com>
To: Edward Cree <ecree.xilinx@...il.com>, bpf@...r.kernel.org
Cc: brouer@...hat.com, netdev@...r.kernel.org,
Stanislav Fomichev <sdf@...gle.com>, martin.lau@...nel.org,
ast@...nel.org, daniel@...earbox.net, alexandr.lobakin@...el.com,
larysa.zaremba@...el.com, xdp-hints@...-project.net,
anthony.l.nguyen@...el.com, yoong.siang.song@...el.com,
boon.leong.ong@...el.com, intel-wired-lan@...ts.osuosl.org,
pabeni@...hat.com, jesse.brandeburg@...el.com, kuba@...nel.org,
edumazet@...gle.com, john.fastabend@...il.com, hawk@...nel.org,
davem@...emloft.net
Subject: Re: [xdp-hints] Re: [PATCH bpf RFC 1/4] xdp: rss hash types
representation
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
Powered by blists - more mailing lists