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 D74FF9C15C4 for ; Fri, 11 Nov 2022 11:41:08 +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=crWvxD+J DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668163267; 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=QNTar+12P1H59OON6fBjXfGGsWJKzpaZOSFcU1s0I+c=; b=crWvxD+JkLKgPwcBTkNf8kt9OrhAcgWxGdbikfFJOdrim3bcp1WsWlW1II6MxAzCmV/89s WqojgHhxIGbbuEN0vcUvaTSQKUOy4INeNA8VGEo5AxAosafh32LtNZ2I8b9UTeOWWBdyiw Z5CaarHq2ShXkV5ceqH0Z+aUe71SHr8= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-592-S_bW4VyqPy2qOjhB1DFPHg-1; Fri, 11 Nov 2022 05:41:04 -0500 X-MC-Unique: S_bW4VyqPy2qOjhB1DFPHg-1 Received: by mail-ej1-f69.google.com with SMTP id hp16-20020a1709073e1000b007adf5a83df7so2836272ejc.1 for ; Fri, 11 Nov 2022 02:41:04 -0800 (PST) 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=QNTar+12P1H59OON6fBjXfGGsWJKzpaZOSFcU1s0I+c=; b=6tHKyk30S3WdD9qTNIakvZ2vvYfdGUi3aL6UL+5ME8uk/SwO9uS2VR4lMU3TbnHWDO epDn5FKUSC3xHuAFirnlIfOFxz8H4aACTYwIZTLVCdcFXK8dinf6LEhrIcuNvy+AGBxn GAMKJWqzSOxVirL8DN20NGclNl6JRn94jfDCBibZhVGlv65G0ZTr2tj8fULD7tKxDCmR q+wvdK3CGtgWmvU+t0TGjlr6DapqnRE7AFpc2X15oDHwngo1rFFwHIJTDxZz3DMOReP0 fpon9nNPeE/of7ADNPlGmbG+pAlpL+Bc+Aj5Hj3iTZYpcZU+kMY3tRFHJjgDUdf0QN10 ApVQ== X-Gm-Message-State: ANoB5pkwAAZMqV4N0DsfSFvhCoAJMkw4lG0ekzu//j78iaQywp6pUUoh 9hiDWaWJa5p294DRM1xsBJu5iqX/C9kGtcI99fBIZYpIaMHMenK2YJfOOAAd/gtrymvVSVPpJuh txkAHb0vQ9nA4G4U01BHn X-Received: by 2002:aa7:cd83:0:b0:461:a7f8:c8c7 with SMTP id x3-20020aa7cd83000000b00461a7f8c8c7mr872846edv.325.1668163263102; Fri, 11 Nov 2022 02:41:03 -0800 (PST) X-Google-Smtp-Source: AA0mqf5Yvj0eHjWgLHwSjcUHmBxgq2MUCkRpUAHfcffqzj9MqAWaLMlKVBaKwON2/4JrFMAsLDM2LQ== X-Received: by 2002:aa7:cd83:0:b0:461:a7f8:c8c7 with SMTP id x3-20020aa7cd83000000b00461a7f8c8c7mr872811edv.325.1668163262867; Fri, 11 Nov 2022 02:41:02 -0800 (PST) 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 y16-20020a1709064b1000b0077a1dd3e7b7sm736940eju.102.2022.11.11.02.41.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Nov 2022 02:41:02 -0800 (PST) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: Date: Fri, 11 Nov 2022 11:41:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 To: John Fastabend , Stanislav Fomichev References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-5-sdf@google.com> <636c4514917fa_13c168208d0@john.notmuch> <636c555942433_13ef3820861@john.notmuch> <636d37629d5c4_145693208e6@john.notmuch> In-Reply-To: <636d37629d5c4_145693208e6@john.notmuch> 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: KMGDYVBNHJ6GEJM6KT6ONLHQKHBVVHKO X-Message-ID-Hash: KMGDYVBNHJ6GEJM6KT6ONLHQKHBVVHKO 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, bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.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 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 10/11/2022 18.39, John Fastabend wrote: > Stanislav Fomichev wrote: >> On Wed, Nov 9, 2022 at 5:35 PM John Fastabend wrote: >>> >>> Stanislav Fomichev wrote: >>>> On Wed, Nov 9, 2022 at 4:26 PM John Fastabend wrote: >>>>> >>>>> 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. >>>> >>>> Initially I've done it mostly so I can have selftests on top of veth >>>> driver, but I'd still prefer to keep it to have working tests. >>> >>> I can't think of a use for it though so its just extra cycles. There >>> is a helper to read the ktime. >> >> As I mentioned in another reply, I wanted something SW-only to test >> this whole metadata story. > > Yeah I see the value there. Also because this is in the veth_xdp_rcv > path we don't actually attach XDP programs to veths except for in > CI anyways. I assume though if someone actually does use this in > prod having an extra _net_timestamp there would be extra unwanted > cycles. > Sorry, but I think it is wrong to add this SW-timestamp to veth. As John already pointed out the BPF-prog can just call ktime helper itself. Plus, we *do* want to use this code path as a fast-path, not just for CI testing. I suggest you use the offloaded VLAN tag instead. >> The idea was: >> - veth rx sets skb->tstamp (otherwise it's 0 at this point) >> - veth kfunc to access rx_timestamp returns skb->tstamp >> - xsk bpf program verifies that the metadata is non-zero >> - the above shows end-to-end functionality with a software driver > > Yep 100% agree very handy for testing just not sure we can add code > to hotpath just for testing. I agree, I really dislike adding code to hotpath just for testing. Using VLAN instead would solve a practical problem, that XDP lacks access to the offloaded VLAN tag. Which is one of the lacking features that XDP-hints targets to add. --Jesper