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.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 92FBD9CD932 for ; Fri, 9 Dec 2022 12:11:05 +0100 (CET) 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=TG14Fizz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670584264; 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=jE6Vr9F6IeGxtuQrcm6iX33balN6CUxBy/zMSS4pEK4=; b=TG14Fizz9n/NV5brZGGgm2XYXL4A3KDmYE48zDPAdSmSw1na/Nm6stI3G3Nh8kNlPn6gsW WMyLN1Ijfpdt0O/9ewMhk6QXDRCckhGZ/+RPSpOsiH8sj4J3VpfZvmgvbtQ9anPfYACbXH C8mZ5GEctJ0r/Wd7fj96kf/uXrZjVH0= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-35-Kiv4pNhmMFS2D5rK5r5XZA-1; Fri, 09 Dec 2022 06:11:02 -0500 X-MC-Unique: Kiv4pNhmMFS2D5rK5r5XZA-1 Received: by mail-ej1-f69.google.com with SMTP id sb2-20020a1709076d8200b007bdea97e799so2943597ejc.22 for ; Fri, 09 Dec 2022 03:11:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=jE6Vr9F6IeGxtuQrcm6iX33balN6CUxBy/zMSS4pEK4=; b=Pw25H9MNrXDs0C6CH99yOA7FPJtwmDjUgFDzowMIOVRHxWd4eeAVPs+WlEdL6TrBgG u2z5D+6ComRLlWCGJstxn4Ejy51XfBGRqiojZCOW9OwhZNAZpzJMICWWFKJStMd1cVno DplmAqaiMFEUUp6DVGopQAcjECVc2WGsnc6tDXjWMBH5QVv48apx7AQFY+jYT/jPwERJ Nixnu+Jd71L0mY7shZ0zR5J6eCzRUc0J7b+J3P8VXVZbaE39nkHT6uaJtabnn108C07Q f79bH3rn3ou/AwimMiQNBI4o0mTvOkgoEaqx8RZTv/x1e32ucH4W26C3oCmaI6TVLpXH wEGQ== X-Gm-Message-State: ANoB5pnsVTqeFfSk63GYuccvPJsQnutXAJV/UFBN6QeGfST4crm8ZJti HGKUykx9Fj4Q2/WEXuRyGyL9RGzLr3l94UBqadAygNHycL1/WQXNMQm87AbBOi3PU5p8bV1FJa0 6lf5iDvswNr8rxzXEyE8q X-Received: by 2002:a17:906:a0d4:b0:7ad:9f03:b330 with SMTP id bh20-20020a170906a0d400b007ad9f03b330mr4610194ejb.62.1670584261399; Fri, 09 Dec 2022 03:11:01 -0800 (PST) X-Google-Smtp-Source: AA0mqf4ElsBLxzKJG5vL8JnhEQ9VfVgdKAWRF7Ozd6jNwS2dlIKePCJQ2Hw+qwhb3AfXEVccBU1Fkw== X-Received: by 2002:a17:906:a0d4:b0:7ad:9f03:b330 with SMTP id bh20-20020a170906a0d400b007ad9f03b330mr4610161ejb.62.1670584261096; Fri, 09 Dec 2022 03:11:01 -0800 (PST) Received: from [192.168.41.200] (83-90-141-187-cable.dk.customer.tdc.net. [83.90.141.187]) by smtp.gmail.com with ESMTPSA id d10-20020a50f68a000000b0045b3853c4b7sm515238edn.51.2022.12.09.03.10.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Dec 2022 03:11:00 -0800 (PST) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: Date: Fri, 9 Dec 2022 12:10:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 To: Stanislav Fomichev , bpf@vger.kernel.org References: <20221206024554.3826186-1-sdf@google.com> <20221206024554.3826186-4-sdf@google.com> In-Reply-To: <20221206024554.3826186-4-sdf@google.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: OFCQY5OJQWAXED47O4TVAGC5ZHKUWPFY X-Message-ID-Hash: OFCQY5OJQWAXED47O4TVAGC5ZHKUWPFY 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, 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 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) > /** > 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); > +