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 6746699E6E0 for ; Fri, 9 Sep 2022 11:42:45 +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=Cilr4QGl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662716564; 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=5iXKFaXwMwTj+qx5rpepg8IFprmEKxi1vIibj/a0OYc=; b=Cilr4QGlzX/+alYF5p0JB6lJ3EjPZW/S0GPshVECaK54zp5iKMTuq1PuA9bTsrK1Ovfohj rTRRwE5o7v9XOFKlJ6ORW310Qw/D01JZbGanPhu9cZ04FN0Usk/KDK/H+/uZ1f+wmmGftq s674OZ0GFkZmqH4cPtbMOqNNsJ9nbKw= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-277-mnP15VS3P1ymf8FVdJyW6A-1; Fri, 09 Sep 2022 05:42:41 -0400 X-MC-Unique: mnP15VS3P1ymf8FVdJyW6A-1 Received: by mail-ej1-f70.google.com with SMTP id gn30-20020a1709070d1e00b0074144af99d1so738688ejc.17 for ; Fri, 09 Sep 2022 02:42:41 -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:content-language:references :to:subject:cc:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date; bh=5iXKFaXwMwTj+qx5rpepg8IFprmEKxi1vIibj/a0OYc=; b=5xRjxUECzYCQkXmavlHMji9qHU5kJe2vVp83g1LfpRg3ITW4+Z5VKDQDRMPjrspYCG NaGAshx9AkiGYyR3aemaIKW9hqkb3Pgt7ZpBIKPX84O2v4aEdDfoB0h/SWUQ6Wf0lMkV 0nPrZUvwmVnOu1lTIag84GnSZQVZAzx6+whY+m2EHUqGvqx/ZX+CAnG7bsV1eLJWj5vs sO+L+p8cSMfeFOY/CEsT6mbL9yTpczPuYVQiWsJMgfaONxVf2SESfrmxtkpWU0KRPtun 8S741PIY+okuOHHnKXOdct6DssCZ8cBMjHo8KcJ6pxpdqwcsNsmfGMqeqoicIVRbDfj1 ve0Q== X-Gm-Message-State: ACgBeo0eCxP9+GHcKcOlb9OBgiFA03LiyB5XLbEA+o6lv+Ael7NucJKi n9cbKWGj10R18Q/buwEvmmNeFr2GgeVxFMw7aSlADNmgh31zE8OubvMLaQDI9VTYsABXrlWiwrL 9jC3KlL9XBI6J9SdJUyD3 X-Received: by 2002:a05:6402:351:b0:44e:1cd2:bd53 with SMTP id r17-20020a056402035100b0044e1cd2bd53mr10507097edw.364.1662716560196; Fri, 09 Sep 2022 02:42:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR7VORBRl+U9ThWWjUQ2G9Wxzqu4Djdg56wVHmV/d5FLJ5A38wxS4QWjJ3t06dJtL6JweATOcw== X-Received: by 2002:a05:6402:351:b0:44e:1cd2:bd53 with SMTP id r17-20020a056402035100b0044e1cd2bd53mr10507075edw.364.1662716559994; Fri, 09 Sep 2022 02:42:39 -0700 (PDT) Received: from [192.168.41.81] (83-90-141-187-cable.dk.customer.tdc.net. [83.90.141.187]) by smtp.gmail.com with ESMTPSA id c19-20020a056402121300b0044f0f51f813sm17379edw.83.2022.09.09.02.42.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Sep 2022 02:42:32 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <593cc1df-8b65-ae9e-37eb-091b19c4d00e@redhat.com> Date: Fri, 9 Sep 2022 11:42:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 To: Maryam Tahhan , Magnus Karlsson , Jesper Dangaard Brouer References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <166256558657.1434226.7390735974413846384.stgit@firesoul> <9aab9ef1-446d-57ab-5789-afffe27801f4@redhat.com> In-Reply-To: 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: YIXQDAMM4Q2WQ4ZFBTIBGOZRDATVBLBP X-Message-ID-Hash: YIXQDAMM4Q2WQ4ZFBTIBGOZRDATVBLBP 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, 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 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). But lets land RX-side first, but make sure we can easily extend for the TX-side. --Jesper