From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by mail.toke.dk (Postfix) with ESMTPS id 8BE669A7B27 for ; Wed, 5 Oct 2022 04:15:37 +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=f2Sydn54 Received: by mail-il1-x130.google.com with SMTP id i9so7474411ilv.9 for ; Tue, 04 Oct 2022 19:15:37 -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=bF3rfNlwAuWQX7FF97PUYgRoxYjQCp+FQ9YtbL3rEM8=; b=f2Sydn540oSzJJmHHZb4OXECOqRdiYpOcytDuEJI99EvyNB/U4JiHK1EREcNiLDI4K ALqouMshmN6HqclSyyXUqDwwEvaYQKz1K/5FVU+rlWhk8F01j9nHyO99IQRSfwEqo0gl RlnDxh4l4iedse7nJKLVkoXD3qhY8kp6ueil/iio1d54ckUjsV2plqwr4bw0rdrN5e+X r0RkvHsuCS1RCcF+wRju/9ghvzd9HqYPJ5fqzJlCOLAZRKLuWQn6hlKJ5llvmcxA/EmT jb2c2hTou9LXZSdJQLZb59FkfpzA9P96d4H8WhmhUwC7Baw1D/s3FmDigKver6k3HDri 88UQ== 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=bF3rfNlwAuWQX7FF97PUYgRoxYjQCp+FQ9YtbL3rEM8=; b=J8ZrJgjtD8V38dBFnfu7JIPUrh9rXWyaM/7WeljSknk5nZp4q9KN3/1EgZ29JaGMvN SGygVp1EkcO4rCA5LHhgyf3rvLrvjMDvezUYVCgNBpBjw59XRBCd3yu8+OOcmkFWW45t 8qUqDX9+9NzMerpqgpyWfvMtUp2OKx2YIK0k57iF027U4Fa2SmCMtDT88POgpVrNShp0 o/RYfIgtuUxALoP2ZrW3f8UIDrKMSls+XDYxWe/t5g/mZiSG/dyocBJb7oe1zzRwy5+k V3FcBlMJRflIwEq2nZpkUGoL0QId4EY4Aa8FHL+N2pqLYYOD5FZh6edaO3Sd8wzS/dTc HIQA== X-Gm-Message-State: ACrzQf22pFbDelt2ZJfc8QKQFaP2pgb9inZXJkp+XYthMV3qmIHC+10p Z0QuxK/FTf70StZ+aesP7Zi5ygDwKklc1bsaWGan0Q== X-Google-Smtp-Source: AMsMyM58qwYn1L3swp5KOVyV1TYqz3USmDJ53no2y3Fo2AXus4qnffPbPjgbAJeyRQxcgM6T6ud2uPcXjosICMHQp+A= X-Received: by 2002:a92:ca0c:0:b0:2f9:204:7a0d with SMTP id j12-20020a92ca0c000000b002f902047a0dmr13639413ils.194.1664936135004; Tue, 04 Oct 2022 19:15:35 -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> <20221004182451.6804b8ca@kernel.org> In-Reply-To: <20221004182451.6804b8ca@kernel.org> From: Stanislav Fomichev Date: Tue, 4 Oct 2022 19:15:24 -0700 Message-ID: To: Jakub Kicinski Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 5XOQHFEVVSHMQQSTCHGPH6R7UDG7ZZND X-Message-ID-Hash: 5XOQHFEVVSHMQQSTCHGPH6R7UDG7ZZND 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 6:24 PM Jakub Kicinski wrote: > > On Tue, 4 Oct 2022 18:02:56 -0700 Stanislav Fomichev wrote: > > +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? > > I'd think so, worst case the driver can put xdp_md into a struct > and container_of() to get to its own stack with whatever fields > it needs. Ack, seems like something worth exploring then. The only issue I see with that is that we'd probably have to extend the loading api to pass target xdp device so we can pre-generate per-device bytecode for those kfuncs? And this potentially will block attaching the same program to different drivers/devices? Or, Martin, did you maybe have something better in mind? > > 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? > > If there is a program on Tx then it'd be trivial - just do the > info <-> descriptor translation in the opposite direction than Rx. > TBH I'm not sure how it'd be done in the current approach, either. Yeah, I don't think it magically works in any case. I'm just trying to understand whether it's something we care to support out of the box or can punt to the bpf programs themselves and say "if you care about forwarding metadata, somehow agree on the format yourself". > Now I questioned the BTF way and mentioned the Tx-side program in > a single thread, I better stop talking... Forget about btf, hail to the new king - kfunc :-D