From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by mail.toke.dk (Postfix) with ESMTPS id 029F19B8000 for ; Thu, 10 Nov 2022 01:26:01 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=XVG/DhIf Received: by mail-pf1-x436.google.com with SMTP id b185so284953pfb.9 for ; Wed, 09 Nov 2022 16:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=UpdZWa52LuHE45E/59xKz1HV+fCoqG7jrw4QGjpnIC4=; b=XVG/DhIfJEUn3b0QY8eG3Gb9QwUyA0OfzXtMM0kLyVKoeklZ/4B8hAw5/UzNiuNEes v/ctjdVk+Ys4C51JBt00u8soglc3ij3CxbQ27hdG6OrG04RVs2cIUVWIOCBDxqA4BxhJ sxs1IjuVr/AX/L5PrCoYRWZ5vT73+TOIeOc5YWPxiHLTZtav84AAUWBLWNMW03Hz9vCM CvZMe6t1R0QXqx0R1c5BY1Ei7b1teAT5Rh3Yitk3ymPR7Da7JQTcfajd11jrHMBLkVi7 sSsynC8h9Wg/k+ohxt9HSxThKAl0cZilGZaq/2YHwiVcFNojoIIrvfKu39o+Hag60uhP F7SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=UpdZWa52LuHE45E/59xKz1HV+fCoqG7jrw4QGjpnIC4=; b=I7/RLjxZfOK+Eoh6qRHXPompYGErKm6mznCvzrxUm5ugCCNjUbj0oYgpiU3uNMCTmu 0q4+HUgivGDP46nttbN2d7LKLs039tM6iaA0V/S6QDAORKLXZc8pVAD/MR53ns4oSJfW 1AhtTDpDx7ybaYUiy/GNaEZrEi8z+Fkd5IY3oRpiOQRO6w3Qh60xIoYycGgpFOo6oTus qCOnMAasrF7e2bqpNBF3bFnEMUNcaiY4DUMY3pP1gAZ9nXyT4N0e9D8KIjegR1vLPgd0 n7OYKyQQvUVVLG6WjVJSMDWTZzkYACRT6QxXf23Mp4iP+5Jv+SQEGrRSXOqMCTv7VW6P jKnw== X-Gm-Message-State: ACrzQf1K4Gi2T44ebHmoZh5lM8pCDo2Ud1pjSFNKnVUOzdcsqs98gb03 hHigmnZO1+54qAtswKtAqJ8= X-Google-Smtp-Source: AMsMyM6t7ofI3W9XzGtTFMxDYkyIg+4vYfWwApy9Usj6siKXAtjwG3/1kqh6vritUkwSEORmBCUuSA== X-Received: by 2002:a65:6c0d:0:b0:46f:a98a:5abf with SMTP id y13-20020a656c0d000000b0046fa98a5abfmr1390604pgu.128.1668039958636; Wed, 09 Nov 2022 16:25:58 -0800 (PST) Received: from localhost ([98.97.44.95]) by smtp.gmail.com with ESMTPSA id p2-20020a17090a868200b0020d51aefb82sm1832784pjn.19.2022.11.09.16.25.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Nov 2022 16:25:58 -0800 (PST) Date: Wed, 09 Nov 2022 16:25:56 -0800 From: John Fastabend To: Stanislav Fomichev , bpf@vger.kernel.org Message-ID: <636c4514917fa_13c168208d0@john.notmuch> In-Reply-To: <20221104032532.1615099-5-sdf@google.com> References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-5-sdf@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: 2BAWU6NNUSTVDC6MRIX6657OKUUUMFC4 X-Message-ID-Hash: 2BAWU6NNUSTVDC6MRIX6657OKUUUMFC4 X-MailFrom: john.fastabend@gmail.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.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: 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 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". > [...] > 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); Just getting to reviewing in depth a bit more. But we hit veth with lots of packets in some configurations I don't think we want to add a __net_timestamp here when vast majority of use cases will have no need for timestamp on veth device. I didn't do a benchmark but its not free. If there is a real use case for timestamping on veth we could do it through a XDP program directly? Basically fallback for devices without hw timestamps. Anyways I need the helper to support hardware without time stamping. Not sure if this was just part of the RFC to explore BPF programs or not. > skb = veth_xdp_rcv_skb(rq, skb, bq, stats); > if (skb) { > if (skb_shared(skb) || skb_unclone(skb, GFP_ATOMIC))