From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 4AD849F9CAC for ; Wed, 29 Mar 2023 14:13:13 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=cDrUyUPk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680091992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lfqSumULYaFAsKVypJ7j6ZB0kW2MYs15+sCfzueyCec=; b=cDrUyUPk5QJMnEcGUO4r0xdEtXU8lM9gFck1ywa52FbqRKukLGsw9F15Pe3b/NxaclBk1w gE1yVV3sDZvjFPOK2UkjbcX4FZgy4KV34D5PSheG0rP3kH2Tf2c8oCxol7yx8YKHKWz0ct YNK9es59dWC7Lj/Pny4tQ+NT+oF4FIs= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-610-mcr22doxMkCGto_Sgy5K7Q-1; Wed, 29 Mar 2023 08:13:10 -0400 X-MC-Unique: mcr22doxMkCGto_Sgy5K7Q-1 Received: by mail-ed1-f72.google.com with SMTP id t14-20020a056402240e00b004fb36e6d670so21956707eda.5 for ; Wed, 29 Mar 2023 05:13:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680091989; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lfqSumULYaFAsKVypJ7j6ZB0kW2MYs15+sCfzueyCec=; b=qJAKNjBM6196OlBEgPu9xStWgaIpeJNM3dUPPOewIMFfWD9c3X/v8q5Q2eNr16hRNW ohkhDr8Gb48hh85gIypOYOutV60qbndbbsttsZUdzEYujag3Qufr1BN1PxuPr39spn6Y z0MU/e2vrSwP8BsHy3pxvhmtJmKfZc3X+0jlN5HmtpNUI5G1ArAIvG0Z5hPnJve0lcwY jGY9ywATcVNDRQvO/wPzGsrzwE9Qjfg2+2ZqQ3DURyPW8p3wQUrbVU5WRQV/4oshPscS GAHDGJJ9ANDDg49TXtzoftnMLCM9u8OefWSESRhvSltEeloUeK0dUJ+ObUntfarK1wc4 pQxg== X-Gm-Message-State: AAQBX9dRjLBfVKLieguHwr68J0qXsujUy6liTLs1gb06N4KQXEeG2xJP k9FRmmvBjt0sP6rAKNFig2Zniu1tGGB4m58LKUWaVtEckVL7VBYuFnko8wHJU5VuZEcw3PwbA38 Yig5GdnqKfUOmlfaO1VYo X-Received: by 2002:aa7:d9c7:0:b0:4fc:6a39:d2f2 with SMTP id v7-20020aa7d9c7000000b004fc6a39d2f2mr18928031eds.18.1680091989739; Wed, 29 Mar 2023 05:13:09 -0700 (PDT) X-Google-Smtp-Source: AKy350ZXEF/duXvlZ3J7zw4ob7Kfy/Cj7JBCPgsJbNT/6kta1V2jSXhTtIA1gCxM40SUZot2im2Vdg== X-Received: by 2002:aa7:d9c7:0:b0:4fc:6a39:d2f2 with SMTP id v7-20020aa7d9c7000000b004fc6a39d2f2mr18928010eds.18.1680091989451; Wed, 29 Mar 2023 05:13:09 -0700 (PDT) Received: from [192.168.42.100] (194-45-78-10.static.kviknet.net. [194.45.78.10]) by smtp.gmail.com with ESMTPSA id i23-20020a508717000000b004af6c5f1805sm16991525edb.52.2023.03.29.05.13.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 05:13:08 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <00b2e31a-4ec6-12fa-a428-38282cafbc58@redhat.com> Date: Wed, 29 Mar 2023 14:13:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: Edward Cree , bpf@vger.kernel.org References: <168003451121.3027256.13000250073816770554.stgit@firesoul> <168003455815.3027256.7575362149566382055.stgit@firesoul> <39543d22-4e71-9696-17f8-5ae22728aa25@gmail.com> In-Reply-To: <39543d22-4e71-9696-17f8-5ae22728aa25@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: WE5UHWIDK6URIRMRYYIH5FNC22HGJIFB X-Message-ID-Hash: WE5UHWIDK6URIRMRYYIH5FNC22HGJIFB X-MailFrom: jbrouer@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: brouer@redhat.com, netdev@vger.kernel.org, Stanislav Fomichev , martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net, alexandr.lobakin@intel.com, larysa.zaremba@intel.com, xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com, yoong.siang.song@intel.com, boon.leong.ong@intel.com, intel-wired-lan@lists.osuosl.org, pabeni@redhat.com, jesse.brandeburg@intel.com, kuba@kernel.org, edumazet@google.com, john.fastabend@gmail.com, hawk@kernel.org, davem@davemloft.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf RFC 1/4] xdp: rss hash types representation List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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