From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by mail.toke.dk (Postfix) with ESMTPS id E83EF99E73B for ; Fri, 9 Sep 2022 12:15:03 +0200 (CEST) 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=SittS2Wo Received: by mail-pf1-x42f.google.com with SMTP id e68so1243818pfe.1 for ; Fri, 09 Sep 2022 03:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=+Yoo2XHsybKaIPn+rG6W0ll92w/5BR8QTYs2PGUujTY=; b=SittS2WotAFX0YP3lK4qge3VAHp3YYnWQyY9HRKwN07YJZr8I/tgFIZNbj1MbfEvMB MJ7cdFboia5tfXq/pshXTAZF6kFWgRnAed+2mgYqsbdbUTwowMliNV9OuQX1SHbcV8VS FCWAkYebaha0FfdyPWekrgH3ezIPLuZv2NitM14vRLgyPysle+SU+OgHos/orjfSAJAa xG4jg6jHCT2cP5rzlSsKMwEUC7PxSskDEuO4W3czADbFgiU5zJ5sy6ft8AN+RvJwKuMI l/fllDqnaJxOqbl3MZ40yVI3zJLX8w4IfKNp8jUrSdxktLK5e7rEQ3rEBKAh/0YBfjeT fQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=+Yoo2XHsybKaIPn+rG6W0ll92w/5BR8QTYs2PGUujTY=; b=e5De0D2+AOI7wEcMBz56upe/S3yQaKoK6GRMNdBPmfpkuBk3yMu9STam03gA6udmmj WXKgb5Eh2ugByH5HJcSqKVC/7QMclFNoXpe4IWvl3e7ITGGUYfhiAQEpviltjXGqKZuw oWgUnx03AelL4qdqaKfdZ4X5DC2pu6yORKso8P59SIyGw4SRV5/Xdb9o1uCH22OsOM4B 98zFkgLh67g//vZnNWtcoQtEsMUjIKxBT2JvA0blbIB9DZ0PsyNj+8vft4VPHkSp59Nj UY1vmgb4QlfeQRteugj2Z62AAkYMgccvsDiAc6Lix0QR2D83AXPeteCREs3iSkg+jhsM vQSw== X-Gm-Message-State: ACgBeo0xuQpEWbspFGsB+tcwfVUa5Hny5SAvYRQHyqQIdHBPFc/s0ZnP vNsHNUZOksvXJqGzV+CDZKt9/RkKoYudCGOgN2Y= X-Google-Smtp-Source: AA6agR6SAsGw1d6dcHyh0x3EJuF3OPUnFAJ46LFMfssd/vgZH643N8h+g0Bb6U6xZkCY6TtIWtcrJhS47C0BuE928FA= X-Received: by 2002:a05:6a00:801:b0:53e:5e35:336c with SMTP id m1-20020a056a00080100b0053e5e35336cmr13672274pfk.62.1662718501337; Fri, 09 Sep 2022 03:15:01 -0700 (PDT) MIME-Version: 1.0 References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <166256558657.1434226.7390735974413846384.stgit@firesoul> <9aab9ef1-446d-57ab-5789-afffe27801f4@redhat.com> <593cc1df-8b65-ae9e-37eb-091b19c4d00e@redhat.com> In-Reply-To: <593cc1df-8b65-ae9e-37eb-091b19c4d00e@redhat.com> From: Magnus Karlsson Date: Fri, 9 Sep 2022 12:14:50 +0200 Message-ID: To: Jesper Dangaard Brouer Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: JTQKCGBANC5DFMHAHVHATYWNAVHE2TJW X-Message-ID-Hash: JTQKCGBANC5DFMHAHVHATYWNAVHE2TJW X-MailFrom: magnus.karlsson@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: Maryam Tahhan , brouer@redhat.com, bpf@vger.kernel.org, netdev@vger.kernel.org, xdp-hints@xdp-project.net, larysa.zaremba@intel.com, memxor@gmail.com, Lorenzo Bianconi , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , dave@dtucker.co.uk, Magnus Karlsson , bjorn@kernel.org X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFCv2 bpf-next 17/18] xsk: AF_XDP xdp-hints support in desc options List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Sep 9, 2022 at 11:42 AM Jesper Dangaard Brouer wrote: > > > On 09/09/2022 10.12, Maryam Tahhan wrote: > > > >>>>> > >>>>> * Instead encode this information into each metadata entry in the > >>>>> metadata area, in some way so that a flags field is not needed (-1 > >>>>> signifies not valid, or whatever happens to make sense). This has the > >>>>> drawback that the user might have to look at a large number of entries > >>>>> just to find out there is nothing valid to read. To alleviate this, it > >>>>> could be combined with the next suggestion. > >>>>> > >>>>> * Dedicate one bit in the options field to indicate that there is at > >>>>> least one valid metadata entry in the metadata area. This could be > >>>>> combined with the two approaches above. However, depending on what > >>>>> metadata you have enabled, this bit might be pointless. If some > >>>>> metadata is always valid, then it serves no purpose. But it might if > >>>>> all enabled metadata is rarely valid, e.g., if you get an Rx timestamp > >>>>> on one packet out of one thousand. > >>>>> > >>> > >>> I like this option better! Except that I have hoped to get 2 bits ;-) > >> > >> I will give you two if you need it Jesper, no problem :-). > >> > > > > Ok I will look at implementing and testing this and post an update. > > Perfect if you Maryam have cycles to work on this. > > Let me explain what I wanted the 2nd bit for. I simply wanted to also > transfer the XDP_FLAGS_HINTS_COMPAT_COMMON flag. One could argue that > is it redundant information as userspace AF_XDP will have to BTF decode > all the know XDP-hints. Thus, it could know if a BTF type ID is > compatible with the common struct. This problem is performance as my > userspace AF_XDP code will have to do more code (switch/jump-table or > table lookup) to map IDs to common compat (to e.g. extract the RX-csum > indication). Getting this extra "common-compat" bit is actually a > micro-optimization. It is up to AF_XDP maintainers if they can spare > this bit. > > > > Thanks folks > > > >>> The performance advantage is that the AF_XDP descriptor bits will > >>> already be cache-hot, and if it indicates no-metadata-hints the AF_XDP > >>> application can avoid reading the metadata cache-line :-). > >> > >> Agreed. I prefer if we can keep it simple and fast like this. > >> > > Great, lets proceed this way then. > > > > > > > Thinking ahead: We will likely need 3 bits. > > The idea is that for TX-side, we set a bit indicating that AF_XDP have > provided a valid XDP-hints layout (incl corresponding BTF ID). (I would > overload and reuse "common-compat" bit if TX gets a common struct). I think we should reuse the "Rx metadata valid" flag for this since this will not be used in the Tx case by definition. In the Tx case, this bit would instead mean that the user has provided a valid XDP-hints layout. It has a nice symmetry, on Rx it is set by the kernel when it has put something relevant in the metadata area. On Tx, it is set by user-space if it has put something relevant in the metadata area. We can also reuse this bit when we get a notification in the completion queue to indicate if the kernel has produced some metadata on tx completions. This could be a Tx timestamp for example. So hopefully we could live with only two bits :-). > But lets land RX-side first, but make sure we can easily extend for the > TX-side. > > --Jesper >