From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by mail.toke.dk (Postfix) with ESMTPS id 7FFCE9CDBCD for ; Fri, 9 Dec 2022 18:47:27 +0100 (CET) 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=gCXVuoMO Received: by mail-pj1-x1034.google.com with SMTP id w4-20020a17090ac98400b002186f5d7a4cso8907375pjt.0 for ; Fri, 09 Dec 2022 09:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zhg6wBBIkUQ+69OvVEryImDiqjxDYG19JHFgfdHHGxo=; b=gCXVuoMOuai7KTph2UPXEkaRCw3rmHtOp3nQFsMXzWAcuy8+pgVwEXKAQqfJwL40G5 tZm91jDnli4IdVGI6mT3VgYxDB2T7fQYEE9BP1o3WpidQmrW1jWvP9x6NjV5J9CSQAKT txVGUPSv+iz2S1zvfKPGH/CR/v/C7zSbpsVvIz1DYpZwBIMf9gVJPp46rw0SlUfXHLgU tuLKsPmiJ2xpp//nJr1RsIJ/slyYMU1k6fGSU9jGVGgCAQbb+yj0L/jDftHZ1VSwVTJ1 62NyhNzqy0+ejcbJTTr9DHLSJAGMQg+Y1HXWaWHoprYb4ZY67+jMKmCh5JdWvomjNXDo 4YoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=zhg6wBBIkUQ+69OvVEryImDiqjxDYG19JHFgfdHHGxo=; b=CL+ArkPgYlIgpE8q/42HTeuKic3RkaWniErmTHdULFcCzQZziiAUhTaHQHwLAj/iv+ 2cPVI8RDdgDWfIh1qTOKdJW9Av/0sE4Ri6kf5TSt5WUviWPQhSrSeeUzmftmQ7tsXy4K 78JymFNfxyqIgj3j/73eTw88gBNSqp0QfI7Gn6DwENnpvcv53u7GkTGJGeFTEH+mxkLf 5jLn4Xmjmt3QiBlEKH4UZzZ75RabM6cLyjVPq/alDvyEZmrR5rvnmsM720hwh1Sk4e9Q ZQlpfSb1AN6B3HOVw/xHiY1GGJ1wPWcl6UGIBLMa7ii44Y0QgPnlM3vmrL+eZfMJ9U6u Tx9A== X-Gm-Message-State: ANoB5plPUuKtcD9gdAJ0qS5PTKmrVc3TugZorn8jDY4rD+Q0pW1WEFVu TnCmt45rkFuS0RaruQgYYCmX/6YtYU8XLBex85sNPA== X-Google-Smtp-Source: AA0mqf5M9kt7HZbyb/j9FaVCke6Rb/YOpFiRFxNSASVPXCoKT5tF5b7Mz/x4Ifu7AAywotM2IBh3MMuMtcBrhpk3lvk= X-Received: by 2002:a17:902:d711:b0:188:c7b2:2dd with SMTP id w17-20020a170902d71100b00188c7b202ddmr79410245ply.88.1670608045940; Fri, 09 Dec 2022 09:47:25 -0800 (PST) MIME-Version: 1.0 References: <20221206024554.3826186-1-sdf@google.com> <20221206024554.3826186-4-sdf@google.com> In-Reply-To: From: Stanislav Fomichev Date: Fri, 9 Dec 2022 09:47:14 -0800 Message-ID: To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: GSTSUBYGZMIQNU2XW3ITDQUX7P5MAWBR X-Message-ID-Hash: GSTSUBYGZMIQNU2XW3ITDQUX7P5MAWBR 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: bpf@vger.kernel.org, brouer@redhat.com, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Dec 9, 2022 at 3:11 AM Jesper Dangaard Brouer wrote: > > > On 06/12/2022 03.45, Stanislav Fomichev wrote: > > There is an ndo handler per kfunc, the verifier replaces a call to the > > generic kfunc with a call to the per-device one. > > > > For XDP, we define a new kfunc set (xdp_metadata_kfunc_ids) which > > implements all possible metatada kfuncs. Not all devices have to > > implement them. If kfunc is not supported by the target device, > > the default implementation is called instead. > > > > Upon loading, if BPF_F_XDP_HAS_METADATA is passed via prog_flags, > > we treat prog_index as target device for kfunc resolution. > > > > [...cut...] > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h > > index 5aa35c58c342..2eabb9157767 100644 > > --- a/include/linux/netdevice.h > > +++ b/include/linux/netdevice.h > > @@ -74,6 +74,7 @@ struct udp_tunnel_nic_info; > > struct udp_tunnel_nic; > > struct bpf_prog; > > struct xdp_buff; > > +struct xdp_md; > > > > void synchronize_net(void); > > void netdev_set_default_ethtool_ops(struct net_device *dev, > > @@ -1611,6 +1612,10 @@ struct net_device_ops { > > ktime_t (*ndo_get_tstamp)(struct net_device *dev, > > const struct skb_shared_hwtstamps *hwtstamps, > > bool cycles); > > + bool (*ndo_xdp_rx_timestamp_supported)(const struct xdp_md *ctx); > > + u64 (*ndo_xdp_rx_timestamp)(const struct xdp_md *ctx); > > + bool (*ndo_xdp_rx_hash_supported)(const struct xdp_md *ctx); > > + u32 (*ndo_xdp_rx_hash)(const struct xdp_md *ctx); > > }; > > > > Would it make sense to add a 'flags' parameter to ndo_xdp_rx_timestamp > and ndo_xdp_rx_hash ? > > E.g. we could have a "STORE" flag that asks the kernel to store this > information for later. This will be helpful for both the SKB and > redirect use-cases. > For redirect e.g into a veth, then BPF-prog can use the same function > bpf_xdp_metadata_rx_hash() to receive the RX-hash, as it can obtain the > "stored" value (from the BPF-prog that did the redirect). > > (p.s. Hopefully a const 'flags' variable can be optimized when unrolling > to eliminate store instructions when flags==0) Are we concerned that doing this without a flag and with another function call will be expensive? For xdp->skb path, I was hoping we would be to do something like: timestamp = bpf_xdp_metadata_rx_hash(ctx); bpf_xdp_metadata_export_rx_hash_to_skb(ctx, timestamp); This should also let the users adjust the metadata before storing it. Am I missing something here? Why would the flag be preferable? > > /** > > diff --git a/include/net/xdp.h b/include/net/xdp.h > > index 55dbc68bfffc..c24aba5c363b 100644 > > --- a/include/net/xdp.h > > +++ b/include/net/xdp.h > > @@ -409,4 +409,33 @@ void xdp_attachment_setup(struct xdp_attachment_info *info, > > > > #define DEV_MAP_BULK_SIZE XDP_BULK_QUEUE_SIZE > > > > +#define XDP_METADATA_KFUNC_xxx \ > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_TIMESTAMP_SUPPORTED, \ > > + bpf_xdp_metadata_rx_timestamp_supported) \ > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_TIMESTAMP, \ > > + bpf_xdp_metadata_rx_timestamp) \ > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_HASH_SUPPORTED, \ > > + bpf_xdp_metadata_rx_hash_supported) \ > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_HASH, \ > > + bpf_xdp_metadata_rx_hash) \ > > + > > +enum { > > +#define XDP_METADATA_KFUNC(name, str) name, > > +XDP_METADATA_KFUNC_xxx > > +#undef XDP_METADATA_KFUNC > > +MAX_XDP_METADATA_KFUNC, > > +}; > > + > > +#ifdef CONFIG_NET > > +u32 xdp_metadata_kfunc_id(int id); > > +#else > > +static inline u32 xdp_metadata_kfunc_id(int id) { return 0; } > > +#endif > > + > > +struct xdp_md; > > +bool bpf_xdp_metadata_rx_timestamp_supported(const struct xdp_md *ctx); > > +u64 bpf_xdp_metadata_rx_timestamp(const struct xdp_md *ctx); > > +bool bpf_xdp_metadata_rx_hash_supported(const struct xdp_md *ctx); > > +u32 bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx); > > + >