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.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 838279AFE4F for ; Fri, 28 Oct 2022 10:40:10 +0200 (CEST) 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=ZOTRP06O DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666946409; 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=3igmv4m9mJVl18Gxms4pQuE8amjlv6pT1bIcnLF+UeQ=; b=ZOTRP06OUO1pNwZVVhW3U48MyPlM5CpZXT1PdtMcrJhQhcQ4vtQjBg2cB7GmB1h8KTSmN8 JYfF8JdE0OllI9AeP2unl6gcHzyECECN+owwts6VD98JhbEu96+iHApazyhO4RfgsBqjOl u9drME3XGvfD1J3SPf/NZhROA9HQ9iY= 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-349-lpK6dTcQODeP6rpfHUVFpA-1; Fri, 28 Oct 2022 04:40:08 -0400 X-MC-Unique: lpK6dTcQODeP6rpfHUVFpA-1 Received: by mail-ed1-f71.google.com with SMTP id dz9-20020a0564021d4900b0045d9a3aded4so2874162edb.22 for ; Fri, 28 Oct 2022 01:40:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:to :content-language:subject:cc:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3igmv4m9mJVl18Gxms4pQuE8amjlv6pT1bIcnLF+UeQ=; b=TKi8b9nu6LTqqgejxoi04GfXrJ8So517k88GLNs1/G/6qLCyXn32fPZHjplOyd4gFb bhLIaO+BgEzdbHntwox8R7gvGS2Umk3jx9VstAw2egBz+22ExtpQ2BaFYM7uzNN6P7Tt yTKwYbLJrlgzNT4afsTc0vwyW6Bd+SeNKU93FETcOZy0zMKofTAwGi4Shp7Ok44E+LNc rikozvwmL2WvnjHzYQy9CdJkMkq02jpNrzCCa7qZLvq62TYk8lxCnf2pXHcot/ShShfP mEXolcbEWTPkHy88DNrXpbEDrm4oKknJVFF7E61lH8emaQZ0/jCbjMAMxq9JDfT5N0MY 0WWg== X-Gm-Message-State: ACrzQf3vBXBLZDbqtbNfcjL5HhW1Y0G6XpgYzyXDCq7wZ+mibZjwCPE2 dt5wbymkSg6wIi+lSA8SKkz1tqQxtjJH0/B5Dz2sxzY2wQZK0/10g9ikvCO5d+lqTUKYt+LMdpH IPRCATP72O3yS1hmclrpc X-Received: by 2002:aa7:d650:0:b0:462:d945:3801 with SMTP id v16-20020aa7d650000000b00462d9453801mr1055331edr.117.1666946407077; Fri, 28 Oct 2022 01:40:07 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4fu5XA4I4vklWepx4GGeridV5qwSCB+s3SM2ZNu/K/oyyr+JE1voYDIrBmDLpM0uqUi3BNYQ== X-Received: by 2002:aa7:d650:0:b0:462:d945:3801 with SMTP id v16-20020aa7d650000000b00462d9453801mr1055300edr.117.1666946406840; Fri, 28 Oct 2022 01:40:06 -0700 (PDT) Received: from [192.168.41.200] (83-90-141-187-cable.dk.customer.tdc.net. [83.90.141.187]) by smtp.gmail.com with ESMTPSA id n30-20020a50935e000000b004575085bf18sm2209753eda.74.2022.10.28.01.40.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 01:40:06 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <1596dd80-246b-80d0-b482-4248691de68e@redhat.com> Date: Fri, 28 Oct 2022 10:40:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 To: Stanislav Fomichev , bpf@vger.kernel.org References: <20221027200019.4106375-1-sdf@google.com> <20221027200019.4106375-3-sdf@google.com> In-Reply-To: <20221027200019.4106375-3-sdf@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 3XY4EREZCDXG3W2UFFLI2RNEEYBF6YFL X-Message-ID-Hash: 3XY4EREZCDXG3W2UFFLI2RNEEYBF6YFL X-MailFrom: jbrouer@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: brouer@redhat.com, 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, Jakub Kicinski , Willem de Bruijn , 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 2/5] 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 27/10/2022 22.00, Stanislav Fomichev wrote: > 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 xdp_buff->priv 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: 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 09682ea3354e..35396dd73de0 100644 > --- a/drivers/net/veth.c > +++ b/drivers/net/veth.c > @@ -597,6 +597,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; > + xdp.priv = NULL; So, why doesn't this supported for normal XDP mode?!? e.g. Where veth gets XDP redirected an xdp_frame. My main use case (for veth) is to make NIC hardware hints available to containers. Thus, creating a flexible fast-path via XDP-redirect directly into containers veth device. (This is e.g. for replacing the inflexible SR-IOV approach with SR-IOV net_devices in the container, with a more cloud friendly approach). How can we extend this approach to handle xdp_frame's from different net_device's ? > > act = bpf_prog_run_xdp(xdp_prog, &xdp); > > @@ -820,6 +821,7 @@ static struct sk_buff *veth_xdp_rcv_skb(struct veth_rq *rq, > > orig_data = xdp.data; > orig_data_end = xdp.data_end; > + xdp.priv = skb; > So, enabling SKB based path only. > act = bpf_prog_run_xdp(xdp_prog, &xdp); > > @@ -936,6 +938,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)) > @@ -1595,6 +1598,33 @@ static int veth_xdp(struct net_device *dev, struct netdev_bpf *xdp) > } > } > > +static int veth_unroll_kfunc(struct bpf_prog *prog, struct bpf_insn *insn) > +{ > + u32 func_id = insn->imm; > + > + if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_HAVE_RX_TIMESTAMP)) { > + /* return true; */ > + insn[0] = BPF_MOV64_IMM(BPF_REG_0, 1); > + return 1; > + } else if (func_id == xdp_metadata_kfunc_id(XDP_METADATA_KFUNC_RX_TIMESTAMP)) { > + /* r1 = ((struct xdp_buff *)r1)->priv; [skb] */ > + insn[0] = BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, > + offsetof(struct xdp_buff, priv)); > + /* if (r1 == NULL) { */ > + insn[1] = BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 1); > + /* return 0; */ > + insn[2] = BPF_MOV64_IMM(BPF_REG_0, 0); > + /* } else { */ > + /* return ((struct sk_buff *)r1)->tstamp; */ > + insn[3] = BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, > + offsetof(struct sk_buff, tstamp)); Just to be clear, this skb->tstamp is a software timestamp, right? > + /* } */ > + return 4; > + } I'm slightly concerned with driver developers maintaining BPF-bytecode on a per-driver bases, but I can certainly live with this if BPF maintainers can. > + > + return 0; > +} > + > static const struct net_device_ops veth_netdev_ops = { > .ndo_init = veth_dev_init, > .ndo_open = veth_open, > @@ -1614,6 +1644,7 @@ static const struct net_device_ops veth_netdev_ops = { > .ndo_bpf = veth_xdp, > .ndo_xdp_xmit = veth_ndo_xdp_xmit, > .ndo_get_peer_dev = veth_peer_dev, > + .ndo_unroll_kfunc = veth_unroll_kfunc, > }; > > #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \