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.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 372159C2827 for ; Tue, 15 Nov 2022 23:46:09 +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=BkF7BoFR DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668552368; 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=h0TWzdfZiE0mSRF2t3lvU4LTFvtVx66OVWvuDeX1yDA=; b=BkF7BoFRqludodF9XpgGZQl+RbJGvYenZmbwEjuesaL14nhjNadMzGjlrSahLxRTpaHNq5 bS0OkovbfUEWNFKmZcDdgh/MHkAlOH0rvDSGTpDde8eEAYvsUVuHrYhddH8FjmaAKMMMM6 omaM+GTg6u4oD6RtlXN6rsb03bClTpI= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-110-kwk5okaVNamopDBL0wfsEg-1; Tue, 15 Nov 2022 17:46:05 -0500 X-MC-Unique: kwk5okaVNamopDBL0wfsEg-1 Received: by mail-ej1-f70.google.com with SMTP id hq18-20020a1709073f1200b007ade8dd3494so8205777ejc.2 for ; Tue, 15 Nov 2022 14:46:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=h0TWzdfZiE0mSRF2t3lvU4LTFvtVx66OVWvuDeX1yDA=; b=rgw35gsabWHGMlUk+ZbtiIxlqEzX5hhGiBITj2Bhf/KX4APWj6nFT2h27V7BmikB/1 np0jH7dStH9kwTfYYp9BC+6Ofxox6oNnWyPFWYdoYHto1jjulPqwQ/Potxz8ywcrPBOD 6iXwRiofSXwN2bysV91U6tRplZxh1PrFuZ27Dnj1UTJAccVuSf2BtGvo6nwMOMLrfwc7 W1CrjYyvyeSTcLPzS1ex0e1aRqi33PepljXGBYGC6gsWEwy1SOfxOsmbjq0l4CPpwJIt KPifOPFCqwrlB8jimE03kOsTmv+Q4fO1bwmtfv/YMcYDhZGcoxCuQ4UZczRdmEEtndVL LOaA== X-Gm-Message-State: ANoB5pkxtfyyIPudvuEXdzvgP4jZUyrrlkULrnOQbfaucHQvyxKMnmYa yYREGKgraRzp35Eh+Uid6EN5e924EOIlmoSx2VUKZaURmfC6O690jWjwZwk4eDcd4/sjd15MY61 GQRq+66aad7GhMNOsuEbf X-Received: by 2002:aa7:c557:0:b0:464:b8b:f526 with SMTP id s23-20020aa7c557000000b004640b8bf526mr17399592edr.342.1668552364336; Tue, 15 Nov 2022 14:46:04 -0800 (PST) X-Google-Smtp-Source: AA0mqf477ZLTO386+YNbJRKiUR5eAcBJ9x/HvUv4FofCMETVmNspFN6yAC94pUyalqcm74dTdZWoCQ== X-Received: by 2002:aa7:c557:0:b0:464:b8b:f526 with SMTP id s23-20020aa7c557000000b004640b8bf526mr17399559edr.342.1668552363894; Tue, 15 Nov 2022 14:46:03 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id we10-20020a170907234a00b00782fbb7f5f7sm6079334ejb.113.2022.11.15.14.46.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 14:46:03 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 38FE17A6D54; Tue, 15 Nov 2022 23:46:02 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Stanislav Fomichev In-Reply-To: References: <20221115030210.3159213-1-sdf@google.com> <20221115030210.3159213-6-sdf@google.com> <87h6z0i449.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 15 Nov 2022 23:46:02 +0100 Message-ID: <8735ajet05.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ED7COJXZQNAU5I35CQ435OKW4N3QAAR2 X-Message-ID-Hash: ED7COJXZQNAU5I35CQ435OKW4N3QAAR2 X-MailFrom: toke@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: 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: 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, str= uct netdev_bpf *xdp) >> > } >> > } >> > >> > +static void veth_unroll_kfunc(const struct bpf_prog *prog, u32 func_i= d, >> > + struct bpf_patch *patch) >> > +{ >> > + if (func_id =3D=3D xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_T= IMESTAMP_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_KFU= NC_RX_TIMESTAMP)) { >> > + /* return ktime_get_mono_fast_ns(); */ >> > + bpf_patch_append(patch, BPF_EMIT_CALL(ktime_get_mono_fas= t_ns)); >> > + } >> > +} >> >> So these look reasonable enough, but would be good to see some examples >> 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 :) -Toke