From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by mail.toke.dk (Postfix) with ESMTPS id 553009C299B for ; Wed, 16 Nov 2022 05:09:36 +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=deo8WWn+ Received: by mail-ot1-x331.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso9736843otr.9 for ; Tue, 15 Nov 2022 20:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=b4x7mjeQl2Jz24wHOq/2fvXva/J1mGhACRnJol7jPpY=; b=deo8WWn+fuUZIplwxsmJEh9XzsmWYNj2tGzi6rVsWWtsKIogoTqgryb3b1EGGy9Hh/ NCk1r4JWOPU1m19XuZdjB32WY+nSsSN9Uzge5TSWw0DRj2jpfQMCK1ljxmP+Cl/9z/Dr fglOGIot/CWkcl0ngvnl9GCkLmZOfnIU3DU9cl8D+sKgRRapgq9FxNznYgdP7g3/BYKT 6pEuGZpk1fCgabOI7KZAvmU4gqTe5pAzhWkVeXD1vJPEojZV2fqGNknT+4Dq8iVfBbGr P/fm6RlHMrGF8RKMvsChIGMI2CBK8+51joRutf85pdgAQFMp2Lx21Q72/g/tkAJToxf9 tI0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=b4x7mjeQl2Jz24wHOq/2fvXva/J1mGhACRnJol7jPpY=; b=LubGoJRNsTpukRLSywLWSZEdWiPGApV2RpMB74Oaky0yXC10AH/BMZ/fy/72rIZ+aM xBmmFh6QG6LZVz+XgekTP9C0jECZa4ekzzmlLEMNikMAmpJJo/1wIEOmXgwEgCqI5eKw hZfUzIQ+x+pZWzhJKzxksCAfyrrZsEYcbcM6XLZX9HKAX0d7vbdUXDJNrzkAdRC5Liz2 ql7re7OW4QKVmD2aUg4ZI9n9apbRvDVNcCgbQ8l/4x7+i0FKELZ8uY+odZJ8FhnrzMMB FIj0OggsboxGAYJE7H2OJqOkHJnk8YIYmlPdvu90YOTf3sOy3jiFvHLKiAhUFgfXEynW ZJOA== X-Gm-Message-State: ANoB5pmJmYZ1JQbs/XaUeD11yFbJHql/9O4j9tZ3+D4ICDSX/w2i0znV 233Itco1VQU2/dPIwgIOkeFkIbrZcXuwXXTa+qyBDg== X-Google-Smtp-Source: AA0mqf6FwxC+oVGRJqnspRiAVKRG4pQlNEbazfh78TgxFxaOZod5nbfv5x1oWe39FiMi423yr6oK2iAbH11LbspDACQ= X-Received: by 2002:a9d:4f06:0:b0:66c:794e:f8c6 with SMTP id d6-20020a9d4f06000000b0066c794ef8c6mr10312938otl.343.1668571775397; Tue, 15 Nov 2022 20:09:35 -0800 (PST) MIME-Version: 1.0 References: <20221115030210.3159213-1-sdf@google.com> <20221115030210.3159213-6-sdf@google.com> <87h6z0i449.fsf@toke.dk> <8735ajet05.fsf@toke.dk> In-Reply-To: <8735ajet05.fsf@toke.dk> From: Stanislav Fomichev Date: Tue, 15 Nov 2022 20:09:24 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: PIR54YSMOMTLKHQ53VTEWJFD7JFYMIQT X-Message-ID-Hash: PIR54YSMOMTLKHQ53VTEWJFD7JFYMIQT 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, 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 , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next 05/11] veth: Support rx timestamp metadata for xdp List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Nov 15, 2022 at 2:46 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Stanislav Fomichev writes: > > > On Tue, Nov 15, 2022 at 8:17 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > >> Stanislav Fomichev writes: > >> > >> > The goal is to enable end-to-end testing of the metadata > >> > for AF_XDP. Current rx_timestamp kfunc returns current > >> > time which should be enough to exercise this new functionality. > >> > > >> > Cc: John Fastabend > >> > Cc: David Ahern > >> > Cc: Martin KaFai Lau > >> > Cc: Jakub Kicinski > >> > Cc: Willem de Bruijn > >> > Cc: Jesper Dangaard Brouer > >> > Cc: Anatoly Burakov > >> > Cc: Alexander Lobakin > >> > Cc: Magnus Karlsson > >> > Cc: Maryam Tahhan > >> > Cc: xdp-hints@xdp-project.net > >> > Cc: netdev@vger.kernel.org > >> > Signed-off-by: Stanislav Fomichev > >> > --- > >> > drivers/net/veth.c | 14 ++++++++++++++ > >> > 1 file changed, 14 insertions(+) > >> > > >> > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > >> > index 2a4592780141..c626580a2294 100644 > >> > --- a/drivers/net/veth.c > >> > +++ b/drivers/net/veth.c > >> > @@ -25,6 +25,7 @@ > >> > #include > >> > #include > >> > #include > >> > +#include > >> > #include > >> > > >> > #define DRV_NAME "veth" > >> > @@ -1659,6 +1660,18 @@ static int veth_xdp(struct net_device *dev, s= truct netdev_bpf *xdp) > >> > } > >> > } > >> > > >> > +static void veth_unroll_kfunc(const struct bpf_prog *prog, u32 func= _id, > >> > + struct bpf_patch *patch) > >> > +{ > >> > + if (func_id =3D=3D xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX= _TIMESTAMP_SUPPORTED)) { > >> > + /* return true; */ > >> > + bpf_patch_append(patch, BPF_MOV64_IMM(BPF_REG_0, 1)); > >> > + } else if (func_id =3D=3D xdp_metadata_kfunc_id(XDP_METADATA_K= FUNC_RX_TIMESTAMP)) { > >> > + /* return ktime_get_mono_fast_ns(); */ > >> > + bpf_patch_append(patch, BPF_EMIT_CALL(ktime_get_mono_f= ast_ns)); > >> > + } > >> > +} > >> > >> So these look reasonable enough, but would be good to see some example= s > >> of kfunc implementations that don't just BPF_CALL to a kernel function > >> (with those helper wrappers we were discussing before). > > > > Let's maybe add them if/when needed as we add more metadata support? > > xdp_metadata_export_to_skb has an example, and rfc 1/2 have more > > examples, so it shouldn't be a problem to resurrect them back at some > > point? > > Well, the reason I asked for them is that I think having to maintain the > BPF code generation in the drivers is probably the biggest drawback of > the kfunc approach, so it would be good to be relatively sure that we > can manage that complexity (via helpers) before we commit to this :) Right, and I've added a bunch of examples in v2 rfc so we can judge whether that complexity is manageable or not :-) Do you want me to add those wrappers you've back without any real users? Because I had to remove my veth tstamp accessors due to John/Jesper objections; I can maybe bring some of this back gated by some static_branch to avoid the fastpath cost?