From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by mail.toke.dk (Postfix) with ESMTPS id 77C4C9FA40E for ; Thu, 30 Mar 2023 21:02:57 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=jfxxG+wl Received: by mail-pj1-x1035.google.com with SMTP id d13so18203638pjh.0 for ; Thu, 30 Mar 2023 12:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680202975; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=p2UKzHLw5AMRHbJxUqeu6Kh29H/LxajcGBLc6kBn8NM=; b=jfxxG+wlfnmoC+ExMU9oSM4vowDpE80ayaaX0O2aBGqC2elIvYflpzHBV9g0BvsEZY xy6wYhpi53/pArSydRtmoRVAkpJ47+6HOoJ/ys8DqhLR0XEPWl1geCfVLPnO86XM/QRs 5M5lmSeM47SYVWpnHWtSjh92WtSPWEMrmBsN0ndbnr4svt5eEX/U9eifrPjCFUjKDWxF 6VgrxjuOvQCwWy7y7Gx4PeORHJ+Umqiq9RGATMWBwQNFyL5cTxzzB86fQGpO0r+Bf6Lx E6Jkc/UAy5cdsW4StBgbk+kOUz91yWbobl/7E3Nh9H7TljwvXrNPn+Bvi2+tZGoOavcs 9qkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680202975; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p2UKzHLw5AMRHbJxUqeu6Kh29H/LxajcGBLc6kBn8NM=; b=koFvzGChV8PEssVInPS45iA1AlNgMdLb62k/F2DSiTx5SWjK3T+Nuz/B9rxxWyyCXM oGbJ5vS7ZZ+bvB+Oep/yh1iCNNvqdCcz8uEy7BGipfT1A0nXLtQKfoib7Eb/xnQuD9uH frk+Rs+kCsr71GnL2TPxHYxzMivEE74qsqJ/iHgs7NyZx0Z+5lT7JjI8FBbYRtKIAzVY bBS9mOFq+KSI0MKpbQfPK5bRnT6Y1nP9F76jsPBUEiVaWSB1X1Gba81Id1pY6Ok9HsRH mW/WQRerOMD9N8tCywT91ZoHsTH7j2bSlcQiRDu8fegzedIeDbDe+QUg7ae/kUx0Kj/t /GUw== X-Gm-Message-State: AAQBX9cxtwVtg5Yrz3eIYSkjIOY0mIzXNlVCW49ipxCg1JrgTgWC5AgV uiWygEcn2EYCTfxh+quo3lu7Y1Iu/ISoM6JHmitmUQ== X-Google-Smtp-Source: AKy350YBv3YNxpoBUla7d5uX/Fr+RDrmMNEjWWjz/UysSH7sQgDbddbgiZwEfCWc8HIRLF59xwmJH1bCBsEZ2qXR3hE= X-Received: by 2002:a17:902:7b89:b0:19f:2c5a:5786 with SMTP id w9-20020a1709027b8900b0019f2c5a5786mr8632202pll.8.1680202974843; Thu, 30 Mar 2023 12:02:54 -0700 (PDT) MIME-Version: 1.0 References: <168019602958.3557870.9960387532660882277.stgit@firesoul> <168019606574.3557870.15629824904085210321.stgit@firesoul> <04256caf-aa28-7e0a-59b1-ecf2b237c96f@redhat.com> In-Reply-To: <04256caf-aa28-7e0a-59b1-ecf2b237c96f@redhat.com> From: Stanislav Fomichev Date: Thu, 30 Mar 2023 12:02:43 -0700 Message-ID: To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: SZLBCI5K4CKB3EVOBXZHCFHO2H6HF2MT X-Message-ID-Hash: SZLBCI5K4CKB3EVOBXZHCFHO2H6HF2MT X-MailFrom: sdf@google.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, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, 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-V3 1/5] 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 Thu, Mar 30, 2023 at 11:56=E2=80=AFAM Jesper Dangaard Brouer wrote: > > > On 30/03/2023 20.35, Stanislav Fomichev wrote: > > On 03/30, Jesper Dangaard Brouer wrote: > >> The RSS hash type specifies what portion of packet data NIC hardware u= sed > >> when calculating RSS hash value. The RSS types are focused on Internet > >> traffic protocols at OSI layers L3 and L4. L2 (e.g. ARP) often get has= h > >> value zero and no RSS type. For L3 focused on IPv4 vs. IPv6, and L4 > >> primarily TCP vs UDP, but some hardware supports SCTP. > > > >> Hardware RSS types are differently encoded for each hardware NIC. Most > >> hardware represent RSS hash type as a number. Determining L3 vs L4 oft= en > >> 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 (enum xdp_rss_hash_type) that > >> contain combinations to be used by drivers, which gets build up with b= its > >> from enum xdp_rss_type_bits. Both enum xdp_rss_type_bits and > >> xdp_rss_hash_type get exposed to BPF via BTF, and it is up to the > >> BPF-programmer to match using these defines. > > > >> This proposal change the kfunc API bpf_xdp_metadata_rx_hash() adding > >> a pointer value argument for provide the RSS hash type. > > > >> Signed-off-by: Jesper Dangaard Brouer > >> --- > >> include/linux/netdevice.h | 3 ++- > >> include/net/xdp.h | 46 +++++++++++++++++++++++++++++++++++= ++++++++++ > >> net/core/xdp.c | 10 +++++++++- > >> 3 files changed, 57 insertions(+), 2 deletions(-) > > > > [...] > >> diff --git a/net/core/xdp.c b/net/core/xdp.c > >> index 528d4b37983d..38d2dee16b47 100644 > >> --- a/net/core/xdp.c > >> +++ b/net/core/xdp.c > >> @@ -734,14 +734,22 @@ __bpf_kfunc int > >> bpf_xdp_metadata_rx_timestamp(const struct xdp_md *ctx, u64 *tim > >> * bpf_xdp_metadata_rx_hash - Read XDP frame RX hash. > >> * @ctx: XDP context pointer. > >> * @hash: Return value pointer. > >> + * @rss_type: Return value pointer for RSS type. > >> + * > >> + * The RSS hash type (@rss_type) specifies what portion of packet hea= ders NIC > >> + * hardware were used when calculating RSS hash value. The type comb= inations > >> + * are defined via &enum xdp_rss_hash_type and individual bits can be= decoded > >> + * via &enum xdp_rss_type_bits. > >> * > >> * Return: > >> * * Returns 0 on success or ``-errno`` on error. > >> * * ``-EOPNOTSUPP`` : means device driver doesn't implement kfunc > >> * * ``-ENODATA`` : means no RX-hash available for this frame > >> */ > >> -__bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, > >> u32 *hash) > >> +__bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, > >> u32 *hash, > >> + enum xdp_rss_hash_type *rss_type) > >> { > > > > [..] > > > >> + BTF_TYPE_EMIT(enum xdp_rss_type_bits); > > > > nit: Do we still need this with an extra argument? > > > > Yes, unfortunately (compiler optimizes out enum xdp_rss_type_bits). > Do notice the difference xdp_rss_type_bits vs xdp_rss_hash_type. > We don't need it for "xdp_rss_hash_type" but need it for > "xdp_rss_type_bits". Ah, I missed that. Then why not expose xdp_rss_type_bits? Keep xdp_rss_hash_type for internal drivers' tables, and export the enum with the bits? > --Jesper >