From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by mail.toke.dk (Postfix) with ESMTPS id D698B9B7018 for ; Wed, 9 Nov 2022 22:34:17 +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=YuWbyjey Received: by mail-io1-xd33.google.com with SMTP id q21so12130072iod.4 for ; Wed, 09 Nov 2022 13:34:17 -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=bCKAwu4bCVG9TGZygS9B/zBZa3cEyi6pjEuB8HyjidI=; b=YuWbyjeyw8Sd4e2WnAEJGyPjCZRsTyS+9XzZinHMsh5Mv3CI6hkDiYzHkcmo24joAJ nNFZmCrJbH3Accs0y4rqHajtY3tjxDtNynWoKq+j9A8ClPF88c5dlrE28DuIO0pHQ58N wzzfAOM5nIw0h8mwVbFCRbB6z9QfZ8YSnmQhjQEdI6I7aQL3kzP2jTrjY622RFNRwQW1 JNjK0aUxNNlsu26imIDp1/tmLCpQQTXx2kW3Zgzoa56iT3gJWHcdPiO1IuH8So/HgIaJ li+ZuPshQdu3Y+O8dWUyAxh33bhRt5gPXm5K8Bw8+hly3svPNg8jiFhFY2LDlsr1Enk5 ROsA== 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=bCKAwu4bCVG9TGZygS9B/zBZa3cEyi6pjEuB8HyjidI=; b=FDaSI1tftLgupDb63D3rntsr3xRO2afppoNPhSPcGYgmVUfwVXARN611GsHqmMfT3T CAt6YlhCHg7Z82OOicj1+6WQU0Cqf5V0fRjvasx6Iu7Zp5z0kwuCSFG9uuvxs4FQiS/2 RiTXcBTi+br6KBvywRl0H908/AhfquTTbjqA+/sqtNtPMK+gMe0cb+6Adakip5qbhUs2 PPMNXSaMFjvS3JItLDmf0+dLVmz4ekQuqzATe2wncT5I8CEy23FKDFsXnZ+xQaFR/Fmn BSeLbS1a0Z9bNT/Hr4gehJIULKbFhxHGy1lXh/MBEWF/xWkLqB+4+COOr9mzhEWEbfTA qSGQ== X-Gm-Message-State: ACrzQf3rdwhtHFp4C5kb8+nkRgURP6Z2/tK3yyzEMeATnb0XBRqB+SJC sOju+ugAzSGfDndPsPXMOH7elU+Hna7O5I2UCIB6Yw== X-Google-Smtp-Source: AMsMyM5i7DK3klvFZuKjaIEdAy/Ka5PHJoe5YnH4EEZnYS5XskMl09c8KrWbkVUvPf+PYqL3SEh/EZ5vZUHlujBADhA= X-Received: by 2002:a02:9401:0:b0:375:6e82:482b with SMTP id a1-20020a029401000000b003756e82482bmr25457585jai.84.1668029655904; Wed, 09 Nov 2022 13:34:15 -0800 (PST) MIME-Version: 1.0 References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-5-sdf@google.com> <87iljoz83d.fsf@toke.dk> In-Reply-To: <87iljoz83d.fsf@toke.dk> From: Stanislav Fomichev Date: Wed, 9 Nov 2022 13:34:05 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: MVNP6DRULED2FYTUQDEDITLUSSJQWSXA X-Message-ID-Hash: MVNP6DRULED2FYTUQDEDITLUSSJQWSXA 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: [RFC bpf-next v2 04/14] 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 Wed, Nov 9, 2022 at 3:21 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Stanislav Fomichev writes: > > > xskxceiver conveniently setups up veth pairs so it seems logical > > to use veth as an example for some of the metadata handling. > > > > We timestamp skb right when we "receive" it, store its > > pointer in new veth_xdp_buff wrapper and generate BPF bytecode to > > reach it from the BPF program. > > > > This largely follows the idea of "store some queue context in > > the xdp_buff/xdp_frame so the metadata can be reached out > > from the BPF program". > > > > 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 | 31 +++++++++++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/drivers/net/veth.c b/drivers/net/veth.c > > index 917ba57453c1..0e629ceb087b 100644 > > --- a/drivers/net/veth.c > > +++ b/drivers/net/veth.c > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #define DRV_NAME "veth" > > @@ -118,6 +119,7 @@ static struct { > > > > struct veth_xdp_buff { > > struct xdp_buff xdp; > > + struct sk_buff *skb; > > }; > > > > static int veth_get_link_ksettings(struct net_device *dev, > > @@ -602,6 +604,7 @@ static struct xdp_frame *veth_xdp_rcv_one(struct ve= th_rq *rq, > > > > xdp_convert_frame_to_buff(frame, xdp); > > xdp->rxq =3D &rq->xdp_rxq; > > + vxbuf.skb =3D NULL; > > > > act =3D bpf_prog_run_xdp(xdp_prog, xdp); > > > > @@ -826,6 +829,7 @@ static struct sk_buff *veth_xdp_rcv_skb(struct veth= _rq *rq, > > > > orig_data =3D xdp->data; > > orig_data_end =3D xdp->data_end; > > + vxbuf.skb =3D skb; > > > > act =3D bpf_prog_run_xdp(xdp_prog, xdp); > > > > @@ -942,6 +946,7 @@ static int veth_xdp_rcv(struct veth_rq *rq, int bud= get, > > struct sk_buff *skb =3D ptr; > > > > stats->xdp_bytes +=3D skb->len; > > + __net_timestamp(skb); > > skb =3D veth_xdp_rcv_skb(rq, skb, bq, stats); > > if (skb) { > > if (skb_shared(skb) || skb_unclone(skb, G= FP_ATOMIC)) > > @@ -1665,6 +1670,31 @@ static int veth_xdp(struct net_device *dev, stru= ct 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_TI= MESTAMP_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_KFUN= C_RX_TIMESTAMP)) { > > + bpf_patch_append(patch, > > + /* r5 =3D ((struct veth_xdp_buff *)r1)->skb; */ > > + BPF_LDX_MEM(BPF_DW, BPF_REG_5, BPF_REG_1, > > + offsetof(struct veth_xdp_buff, skb)), > > + /* if (r5 =3D=3D NULL) { */ > > + BPF_JMP_IMM(BPF_JNE, BPF_REG_5, 0, 2), > > + /* return 0; */ > > + BPF_MOV64_IMM(BPF_REG_0, 0), > > + BPF_JMP_A(1), > > + /* } else { */ > > + /* return ((struct sk_buff *)r5)->tstamp; */ > > + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_5, > > + offsetof(struct sk_buff, tstamp)), > > + /* } */ > > I don't think it's realistic to expect driver developers to write this > level of BPF instructions for everything. With the 'patch' thing it > should be feasible to write some helpers that driver developers can use, > right? E.g., this one could be: > > bpf_read_context_member_u64(size_t ctx_offset, size_t member_offset) > > called as: > > bpf_read_context_member_u64(offsetof(struct veth_xdp_buff, skb), offsetof= (struct sk_buff, tstamp)); > > or with some macro trickery we could even hide the offsetof so you just > pass in types and member names? Definitely; let's start with the one you're proposing, we'll figure out the rest as we go; thx! > -Toke >