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 C6AAD9CDA79 for ; Fri, 9 Dec 2022 15:37:53 +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=haToKFf9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670596672; 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=kU+z23dnqt2NuNhcLN5cEmJinJB43iazq7wqR0qgf8g=; b=haToKFf9VSuQNQj3fL8mp5detndRSDN79NfHrE+q8A86YlPePrUSzZMnWFXZQylUwiE/XO URUPY+Q+lIIXRb+hnECtaQ5PNeik/R2Gs10Qcz0KTukSU+FdQiDhebcKgjK0nBtQF8ObV0 RQnAy8xE01DYn1L6jE8vqBCqVll44fQ= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-500-lsFHVlCoMpuGaB2XEO_6Ww-1; Fri, 09 Dec 2022 09:37:51 -0500 X-MC-Unique: lsFHVlCoMpuGaB2XEO_6Ww-1 Received: by mail-ed1-f70.google.com with SMTP id t4-20020a056402524400b004620845ba7bso1494292edd.4 for ; Fri, 09 Dec 2022 06:37:50 -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=kU+z23dnqt2NuNhcLN5cEmJinJB43iazq7wqR0qgf8g=; b=L/K1m0PF4dtgWr/sl/lKZLJTFSo5RhMbUvO6q1A8AMo7lWBVYyhptfTbQGhCqxomnC 6ArauZIOPiUTqRxxIuGB5pj8zVsR06w1PfteuOWjMhmj+8XEt4pOchhRPPYhO+knaMnu 4tNSVA+pv7jv46j6gpdS7rnVyGRT2BSPaUY7+OKYi8V+V4DQSvIBZ8I0Rrtj+DwhofsK fWEuWCRhFHpWiNDeu3d/PMY3VqSOKGyR06S30YPp/AeUTSjdRRCeC3Z/gYvGb6l71Wv8 N/vC8mmHDq90sBbodt2L/jTgzlSGOfWmMoF/mFnENjk419pgqhZjDyIak+YUWUJiTaks bjEg== X-Gm-Message-State: ANoB5pmq5p6Uvw0NEx89md/3zykvPVdQ/ZXn1GVMy7z9Qk5KP8ArtpRQ xXWgfGuLctEeYhvWxVcUCRla6FOk4TeCczcskDdInMe1xRk1Ha+1ixYdIktCgvxCEk/8tCv8E6w 2p3eslp5l3KkPYN01yE6K X-Received: by 2002:a17:907:b607:b0:7ae:f042:de0a with SMTP id vl7-20020a170907b60700b007aef042de0amr5623184ejc.48.1670596667625; Fri, 09 Dec 2022 06:37:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf5Gymtho0UD4hvufqXRvIZHEVz0hyXMmhci5jsiyXEsDmdMOjQPWfEeLfqcovjq4coVOyjB4A== X-Received: by 2002:a17:907:b607:b0:7ae:f042:de0a with SMTP id vl7-20020a170907b60700b007aef042de0amr5623025ejc.48.1670596665435; Fri, 09 Dec 2022 06:37:45 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id p13-20020a17090653cd00b007b27fc3a1ffsm610673ejo.121.2022.12.09.06.37.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Dec 2022 06:37:35 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 2CA4C82EB3A; Fri, 9 Dec 2022 15:37:34 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jesper Dangaard Brouer , Saeed Mahameed , Stanislav Fomichev In-Reply-To: <66fa1861-30dd-6d00-ed14-0cf4a6b39f3c@redhat.com> References: <20221206024554.3826186-1-sdf@google.com> <20221206024554.3826186-12-sdf@google.com> <875yellcx6.fsf@toke.dk> <87359pl9zy.fsf@toke.dk> <87tu25ju77.fsf@toke.dk> <87o7sdjt20.fsf@toke.dk> <66fa1861-30dd-6d00-ed14-0cf4a6b39f3c@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 09 Dec 2022 15:37:34 +0100 Message-ID: <87fsdok5ht.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: PPZDGIA64Z3BDYZM6NKVHX6UNHLUYB2Z X-Message-ID-Hash: PPZDGIA64Z3BDYZM6NKVHX6UNHLUYB2Z 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: brouer@redhat.com, Alexei Starovoitov , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , Saeed Mahameed , David Ahern , Jakub Kicinski , Willem de Bruijn , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, Network Development X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v3 11/12] mlx5: 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: Jesper Dangaard Brouer writes: >> hash/timestap/csum is per packet .. vlan as well depending how you look at >> it.. > > True, we cannot cache this as it is *per packet* info. > >> Sorry I haven't been following the progress of xdp meta data, but why did >> we drop the idea of btf and driver copying metdata in front of the xdp >> frame ? >> > > It took me some time to understand this new approach, and why it makes > sense. This is my understanding of the design direction change: > > This approach gives more control to the XDP BPF-prog to pick and choose > which XDP hints are relevant for the specific use-case. BPF-prog can > also skip storing hints anywhere and just read+react on value (that e.g. > comes from RX-desc). > > For the use-cases redirect, AF_XDP, chained BPF-progs, XDP-to-TC, > SKB-creation, we *do* need to store hints somewhere, as RX-desc will be > out-of-scope. I this patchset hand-waves and says BPF-prog can just > manually store this in a prog custom layout in metadata area. I'm not > super happy with ignoring/hand-waving all these use-case, but I > hope/think we later can extend this some more structure to support these > use-cases better (with this patchset as a foundation). I don't think this approach "hand-waves" the need to store the metadata, it just declares it out of scope :) Which makes sense, because "accessing the metadata" and "storing it for later use" are two different problems, where the second one build on top of the first one. I.e., once we have a way to access the data, we can build upon that to have a way to store it somewhere. > I actually like this kfunc design, because the BPF-prog's get an > intuitive API, and on driver side we can hide the details of howto > extract the HW hints. +1 >> hopefully future HW generations will do that for free .. > > True. I think it is worth repeating, that the approach of storing HW > hints in metadata area (in-front of packet data) was to allow future HW > generations to write this. Thus, eliminating the 6 ns (that I showed it > cost), and then it would be up-to XDP BPF-prog to pick and choose which > to read, like this patchset already offers. > > This patchset isn't incompatible with future HW generations doing this, > as the kfunc would hide the details and point to this area instead of > the RX-desc. While we get the "store for free" from hardware, I do > worry that reading this memory area (which will part of DMA area) is > going to be slower than reading from RX-desc. Agreed (choked on the "isn't incompatible" double negative at first). If the hardware stores the data next to the packet data, the kfuncs can just read them from there. If it turns out that we can even make the layout for some fields the same across drivers, we could even have the generic kfunc implementations just read this area (which also nicely solves the "storage" problem). -Toke