From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by mail.toke.dk (Postfix) with ESMTPS id EBF7C9CFCB0 for ; Wed, 14 Dec 2022 19:44:16 +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=Q0cwVZkQ Received: by mail-pj1-x1029.google.com with SMTP id 3-20020a17090a098300b00219041dcbe9so112244pjo.3 for ; Wed, 14 Dec 2022 10:44:16 -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=Cw3B/81u2H2+N7G7TRZJRJnoU5pzkMNrTipR+QI1Vp8=; b=Q0cwVZkQj/5qxPW5Mr42GmlV37bQqcySReLDNfHGO4dIbWXhxVQS//C3n4pBa/7SYh rMHfjkk2sSlHm+F/HlgDML3TXO8QNZa76xfPB9VV7bRRcAq1yTvCbCfQqtt508LRhdqF mBJttilrVkUacrwHuFUNdCoyINVUYwjXuDSqTHY3wuIj65hSUIAerqZufcc2NvBSw4kh /Cr1BUSvKv5JIUIiq+/FhusoNFOwGFD8F9oqTG3fgFJ74dtgtruvgziXiur9f2slv0rG VjO4fLw7UQrknzq81f3bAIIEIIcb/VT+FRUt+3O510VfnU/FP3IFifsie1KLHLRw7Wmx bp2A== 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=Cw3B/81u2H2+N7G7TRZJRJnoU5pzkMNrTipR+QI1Vp8=; b=TuPjlGeIB1yTSrfP8aFIrpb5AMlAgZFn7EiFAXEDzZAy7RnnLeWSPgGceXvbkjrZXQ m0DfatgcdqA8868dCHIJhfyO1fwNJhPQFUIHBX23Rx66Wo5GjwiUqLGv47FSH+dxgqf0 zwy51Vopjfz4+h7ppYeujv36gpCbkUO5ZqPk/hlzbK27PzgFmo64kZBKRLBziv6oYClG b376uB3zL7i0NpqbbXip/RwIvFCjRvr1tXgaoPjohEjMn9q7uiV7wUM88fe6gKZQBrco mLYrTI1fIv1RZwgve+r31lMYunduYEEEbkhcQHSEqyJcaA3SYylBntzUsrT0GtCiPmll aoXQ== X-Gm-Message-State: AFqh2kp6rNbhAICi7r1gui6dBiFWmZPom6WeUaZvi1MQo+1comyNs/q8 k7MxRLrAgOri2LD6Adr/MtxXg2Y1KNfzb9z4643XhA== X-Google-Smtp-Source: AMrXdXsE/DTSMUCTV3gxuVwfJz087oOaEvx9mV4YqNsqVW2nzRFnf5s3qjXuJnAzjA3MV5MGBwmxJlqxGonZh6GxORU= X-Received: by 2002:a17:90a:c389:b0:218:9107:381b with SMTP id h9-20020a17090ac38900b002189107381bmr390975pjt.75.1671043454940; Wed, 14 Dec 2022 10:44:14 -0800 (PST) MIME-Version: 1.0 References: <20221213023605.737383-1-sdf@google.com> <20221213023605.737383-9-sdf@google.com> <7ca8ac2c-7c07-a52f-ec17-d1ba86fa45ab@redhat.com> <4bac619d-8767-1364-1924-78c05b1ecf88@redhat.com> <87a63qgt30.fsf@toke.dk> In-Reply-To: From: Stanislav Fomichev Date: Wed, 14 Dec 2022 10:44:02 -0800 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: N5A5KDFRR234WA7HTFTK3Z5BIV2DNYRH X-Message-ID-Hash: N5A5KDFRR234WA7HTFTK3Z5BIV2DNYRH 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: brouer@redhat.com, bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, 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 , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Jesper Dangaard Brouer X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v4 08/15] veth: Support RX XDP metadata List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Dec 14, 2022 at 10:09 AM Martin KaFai Lau wr= ote: > > On 12/14/22 2:47 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Jesper Dangaard Brouer writes: > > > >> On 13/12/2022 21.42, Stanislav Fomichev wrote: > >>> On Tue, Dec 13, 2022 at 7:55 AM Jesper Dangaard Brouer > >>> wrote: > >>>> > >>>> > >>>> On 13/12/2022 03.35, Stanislav Fomichev wrote: > >>>>> The goal is to enable end-to-end testing of the metadata for AF_XDP= . > >>>>> > >>>>> 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 | 24 ++++++++++++++++++++++++ > >>>>> 1 file changed, 24 insertions(+) > >>>>> > >>>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c > >>>>> index 04ffd8cb2945..d5491e7a2798 100644 > >>>>> --- a/drivers/net/veth.c > >>>>> +++ b/drivers/net/veth.c > >>>>> @@ -118,6 +118,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 +603,7 @@ static struct xdp_frame *veth_xdp_rcv_one(struc= t veth_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); > >>>>> > >>>>> @@ -823,6 +825,7 @@ static struct sk_buff *veth_xdp_rcv_skb(struct = veth_rq *rq, > >>>>> __skb_push(skb, skb->data - skb_mac_header(skb)); > >>>>> if (veth_convert_skb_to_xdp_buff(rq, xdp, &skb)) > >>>>> goto drop; > >>>>> + vxbuf.skb =3D skb; > >>>>> > >>>>> orig_data =3D xdp->data; > >>>>> orig_data_end =3D xdp->data_end; > >>>>> @@ -1601,6 +1604,21 @@ static int veth_xdp(struct net_device *dev, = struct netdev_bpf *xdp) > >>>>> } > >>>>> } > >>>>> > >>>>> +static int veth_xdp_rx_timestamp(const struct xdp_md *ctx, u64 *ti= mestamp) > >>>>> +{ > >>>>> + *timestamp =3D ktime_get_mono_fast_ns(); > >>>> > >>>> This should be reading the hardware timestamp in the SKB. > >>>> > >>>> Details: This hardware timestamp in the SKB is located in > >>>> skb_shared_info area, which is also available for xdp_frame (current= ly > >>>> used for multi-buffer purposes). Thus, when adding xdp-hints "store= " > >>>> functionality, it would be natural to store the HW TS in the same pl= ace. > >>>> Making the veth skb/xdp_frame code paths able to share code. > >>> > >>> Does something like the following look acceptable as well? > >>> > >>> *timestamp =3D skb_hwtstamps(_ctx->skb)->hwtstamp; > > If it is to test the kfunc and ensure veth_xdp_rx_timestamp is called, th= is > alone should be enough. skb_hwtstamps(_ctx->skb)->hwtstamp should be 0 if > hwtstamp is unavailable? The test can initialize the 'u64 *timestamp' ar= g to > non-zero first. If it is not good enough, an fentry tracing can be done = to > veth_xdp_rx_timestamp to ensure it is called also. There is also fmod_re= t that > could change the return value but the timestamp is not the return value t= hough. > > If the above is not enough, another direction of thought could be doing i= t > through bpf_prog_test_run_xdp() but it will need a way to initialize the > veth_xdp_buff. > > That said, overall, I don't think it is a good idea to bend the > veth_xdp_rx_timestamp kfunc too much only for testing purpose unless ther= e is no > other way out. Oh, good point about just making sure veth_xdp_rx_timestamp returns timestamp=3D0. That should be enough, thanks!