From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by mail.toke.dk (Postfix) with ESMTPS id 769C19A7AAE for ; Wed, 5 Oct 2022 03:03:10 +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=ZC9ITz6o Received: by mail-il1-x12b.google.com with SMTP id g13so4938775ile.0 for ; Tue, 04 Oct 2022 18:03:10 -0700 (PDT) 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; bh=yJ/v5flpgbqzzKOS0FYLrm0MIv5XQqM/Le3ziZYOQHI=; b=ZC9ITz6o6buy6WwUn+AaoAusFCkjmocrVpdJxCp5hHjv2CRY8MPtaGrVAMXRv2VGix zYKcn3Z24SHeHcyk1I9x8BUFFVOFPuIk8Wk3ylLe42RZ0NEdKWBXCCzn6Hzy9PsSVBEk xllLfHngj6nxaYhz93NeNw+xexgMO6PfwmmonzAB0ivkRapnTONWOiTCAJqdzuvWLjBk teWXLcTESrPwRpzIvyLZ/iRmUgojm0Ky+LyJkS9cfcsU3CUvu1AXxyYvypkSOTZ8Rvap huqdoPP5WALMw/WBPzo19pm9krfggmqvkQ/J+TWxHu9S6h7XIRo5kDWdzAV+Sh1X51Th Rliw== 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; bh=yJ/v5flpgbqzzKOS0FYLrm0MIv5XQqM/Le3ziZYOQHI=; b=rvtdoaSFG95fvHe7BQ/rlNOZ0CIC992EZo6C6lsy37O5fE+KBhvMb1G4ZI1YZ3zoI/ CinmONmymXC/fMKsa699bPeIOERaClO9U6oUgN2LGeCs2aWZ11opQ02Ww7rltOLASb2C 4DiMioSVfDBHjetWrTgFN4akE4gjBuQxyUCncWG4D6WBlDAPxS/SdMoIO2Jgqcq2Airc tcFK74uXHAbIHL1wg3RtbTq5Y71ZJx9Gyv4YlgGr4Rne73Nd5wPLGNEXvHA4Tgewk+5J XPZ7l5osJ1mFOKMO2RcF+lYc3WSWsN4r6UsM+ldG981CqBc69b1J95r6pFRTT8lNa6+0 PIPA== X-Gm-Message-State: ACrzQf1X8QQ8OSi1KOohbCSm6Nly2DOH2ZjXeHo0DOhMWBPhO+4R6T1M NYraDvRSmPqjAQK7q4r0WJsEQhos1fdDXqAh2ggMsw== X-Google-Smtp-Source: AMsMyM62nBzxdO94Lozo3o57NKTA5aneTHuundWNjPY59L8dQ2zGbFTKjlEmTK3cKl7Np1mP7zA1f10MgH6ZT2e0qZ8= X-Received: by 2002:a05:6e02:17cb:b0:2f9:1fb4:ba3b with SMTP id z11-20020a056e0217cb00b002f91fb4ba3bmr12821161ilu.257.1664931788439; Tue, 04 Oct 2022 18:03:08 -0700 (PDT) MIME-Version: 1.0 References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <35fcfb25-583a-e923-6eee-e8bbcc19db17@redhat.com> <5ccff6fa-0d50-c436-b891-ab797fe7e3c4@linux.dev> <20221004175952.6e4aade7@kernel.org> In-Reply-To: <20221004175952.6e4aade7@kernel.org> From: Stanislav Fomichev Date: Tue, 4 Oct 2022 18:02:56 -0700 Message-ID: To: Jakub Kicinski Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: U52PW3MTBYYVJLFSZ5QMQWJV4AJ77C4N X-Message-ID-Hash: U52PW3MTBYYVJLFSZ5QMQWJV4AJ77C4N 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: Martin KaFai Lau , Jesper Dangaard Brouer , brouer@redhat.com, bpf@vger.kernel.org, netdev@vger.kernel.org, xdp-hints@xdp-project.net, larysa.zaremba@intel.com, memxor@gmail.com, Lorenzo Bianconi , mtahhan@redhat.com, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , dave@dtucker.co.uk, Magnus Karlsson , bjorn@kernel.org X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFCv2 bpf-next 00/18] XDP-hints: XDP gaining access to HW offload hints via BTF List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Oct 4, 2022 at 5:59 PM Jakub Kicinski wrote: > > On Tue, 4 Oct 2022 17:25:51 -0700 Martin KaFai Lau wrote: > > A intentionally wild question, what does it take for the driver to return the > > hints. Is the rx_desc and rx_queue enough? When the xdp prog is calling a > > kfunc/bpf-helper, like 'hwtstamp = bpf_xdp_get_hwtstamp()', can the driver > > replace it with some inline bpf code (like how the inline code is generated for > > the map_lookup helper). The xdp prog can then store the hwstamp in the meta > > area in any layout it wants. > > Since you mentioned it... FWIW that was always my preference rather than > the BTF magic :) The jited image would have to be per-driver like we > do for BPF offload but that's easy to do from the technical > perspective (I doubt many deployments bind the same prog to multiple > HW devices).. +1, sounds like a good alternative (got your reply while typing) I'm not too versed in the rx_desc/rx_queue area, but seems like worst case that bpf_xdp_get_hwtstamp can probably receive a xdp_md ctx and parse it out from the pre-populated metadata? Btw, do we also need to think about the redirect case? What happens when I redirect one frame from a device A with one metadata format to a device B with another?