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 F2AD79B4B0C for ; Wed, 9 Nov 2022 12:21:49 +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=O2yWmzuC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667992908; 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: in-reply-to:in-reply-to:references:references; bh=iu6WVQzYd6QVJ2aRddjHWcCe6Wgq/3xvvgm9HbBXmlM=; b=O2yWmzuC4D45ESD2agAVorTk+YM/AB9PlLh9vjru1sWEkqnncVbt6QIfCh/f9+IqIo3wRW TnInpZG7lTu+xggQ32dCH77KMo7soe90XIVCCM5k8qYUo11WDu9hkOgI+IY8Qzn/HND0nv BsWqr+mDR48bu+ZM+BXbsICw6xtwM0g= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-574-ArI8dcAfNuKjQb-Q8hla4A-1; Wed, 09 Nov 2022 06:21:47 -0500 X-MC-Unique: ArI8dcAfNuKjQb-Q8hla4A-1 Received: by mail-ed1-f71.google.com with SMTP id f17-20020a056402355100b00466481256f6so6791433edd.19 for ; Wed, 09 Nov 2022 03:21:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=iu6WVQzYd6QVJ2aRddjHWcCe6Wgq/3xvvgm9HbBXmlM=; b=Ov9eaRajVipYrchsyChXL3cMo5ihHqvhvtMZoe78i6wKmKv0WMkwzFxHM3OaNsDQ01 dvNwQ3M0eD1/U8qBZyPBYorDb4FhUMH2JfSe7Zpkc5EYDF+j6fggqkdcavhhalkTSNAg J471x1G2WHP8/KDbgHUCOWAMIJM1xsR3SRnnCG9eSdfgZ1JyoNXCi/1TLTulK0RSTAWi Q0R+myEhuvnGWSXKb+mfNhz24E+2LT5SxIIHLGk8j7AlDQ+7uHU7VB0DUlKcvoCNOlKI 4v3N1vEZ5sP6MP1gjQHslsRb5SUEte/u+8cJvUIdJ6nVkzTK42kdjYNzb0cZORdpnM0R 416A== X-Gm-Message-State: ANoB5pl3p167muT6Oe1W7gM8R2YDmS7BDnI4l++QIpUHBZKFhoKLoE0g r6Pdu1jm7XzKHMUgtojSJcfN0KdS3IIcmpGsoZgzcEex51iC1ArVM3dZkV62QMjlTqxcmcdh8Wm cU6ks7O5Ye4F0HImrhQFG X-Received: by 2002:a17:907:778a:b0:7ae:743c:61c1 with SMTP id ky10-20020a170907778a00b007ae743c61c1mr10018331ejc.511.1667992904091; Wed, 09 Nov 2022 03:21:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf6TQe48yQLkJdpv+TaqjpnyJXWIfV1jTzYt4LWLlnCMU7wmlEFns3k5hY9omtckGMfN0SMwrQ== X-Received: by 2002:a17:907:778a:b0:7ae:743c:61c1 with SMTP id ky10-20020a170907778a00b007ae743c61c1mr10018283ejc.511.1667992903225; Wed, 09 Nov 2022 03:21:43 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id qp18-20020a170907207200b007838e332d78sm5687061ejb.128.2022.11.09.03.21.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Nov 2022 03:21:42 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 4C42678250B; Wed, 9 Nov 2022 12:21:42 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Stanislav Fomichev , bpf@vger.kernel.org In-Reply-To: <20221104032532.1615099-5-sdf@google.com> References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-5-sdf@google.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 09 Nov 2022 12:21:42 +0100 Message-ID: <87iljoz83d.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: 5OKL344SISJP5EZJN4LKO2EWGDHHOY5Y X-Message-ID-Hash: 5OKL344SISJP5EZJN4LKO2EWGDHHOY5Y 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: 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, sdf@google.com, 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.5 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: 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 veth_rq *rq, > > xdp_convert_frame_to_buff(frame, xdp); > xdp->rxq = &rq->xdp_rxq; > + vxbuf.skb = NULL; > > act = 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 = xdp->data; > orig_data_end = xdp->data_end; > + vxbuf.skb = skb; > > act = bpf_prog_run_xdp(xdp_prog, xdp); > > @@ -942,6 +946,7 @@ static int veth_xdp_rcv(struct veth_rq *rq, int budget, > struct sk_buff *skb = ptr; > > stats->xdp_bytes += skb->len; > + __net_timestamp(skb); > skb = veth_xdp_rcv_skb(rq, skb, bq, stats); > if (skb) { > if (skb_shared(skb) || skb_unclone(skb, GFP_ATOMIC)) > @@ -1665,6 +1670,31 @@ static int veth_xdp(struct net_device *dev, struct netdev_bpf *xdp) > } > } > > +static void veth_unroll_kfunc(const struct bpf_prog *prog, u32 func_id, > + struct bpf_patch *patch) > +{ > + if (func_id == 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 == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP)) { > + bpf_patch_append(patch, > + /* r5 = ((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 == 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? -Toke