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 39CB09C1558 for ; Fri, 11 Nov 2022 10:45:06 +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=dRFxvM3I DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668159905; 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=X084KrwwJ1RXuJoA4D6f6jaWiEU8X5AnTsYd0QVhIzM=; b=dRFxvM3IdwBdud3tdez+ir1WoIxlL9yYLFUsOxJm3uQvErE33ZqVXLeCCYzHgbUDYpc+XI 64TvO6ZXMxABQOpAJAFtS/UzTrOmm7SPWVqlpyS7PJ8YrjFo4uhKV2OPidsaFCcnBdYaXQ PZm0sH/p4bKmr5nqda1/qqhcpd0rZX4= 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-563-d3foLOOMM2CoKPH3a7vu_w-1; Fri, 11 Nov 2022 04:45:03 -0500 X-MC-Unique: d3foLOOMM2CoKPH3a7vu_w-1 Received: by mail-ej1-f70.google.com with SMTP id sg37-20020a170907a42500b007adaedb5ba2so2747331ejc.18 for ; Fri, 11 Nov 2022 01:45:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=zNf7ZXOT6z9fd4Tt6B6QdA1QJpIGsL1BM+FjfGyIKL0=; b=7NP/+wEASxbSogwinGp86QEObmTE4tH9kEIKoZV/q8aDoFRX17M5PAuSMPBmxlj0C7 h8Ny2T01ciVG+5TPHq+jpceEv7DK4lJVH4Wl73psLSfKGBmeSTkolg5sAzPFgcE7ePYw AKG+rowhfe86q8nzpPtfrJUU0r0gHuApbLuNKZJ5ltyU9RfztMDJtoWfcjccqg3AQhEM N8x119omqZWnn/m0iUL0G88Z8ky00Rq1ckYweOI07LRIIT3c/Ns+P5a5BUFt2wxSxX6c pt+B4cUmbbbzGmFTWVZ0r7WhQaBvFKiI6XTCapkwTpqkokGNJBHyGqEgi6LaZBWW4QR6 T8Xg== X-Gm-Message-State: ANoB5pm4sfTi5SkEwylkOvic8Nr1DBltVfcYsBsB6raMTeqHk48bwd6b K/MNMeMTlMbxPXML4j+EccHBTGohRiB/+rmZccQPXAjtgY94oLpLQ2MROlqWMIq6y5T7uALZDVq ycjYugjdqR2arPOFf9tBB X-Received: by 2002:aa7:c702:0:b0:461:8156:e0ca with SMTP id i2-20020aa7c702000000b004618156e0camr733241edq.271.1668159902255; Fri, 11 Nov 2022 01:45:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf51QzkFNHVdKXxekMd802nRscfJVnL2TqOzrhRzF34Md3cQPmIKH7X2QQ2HioI6VTLXL5UqJw== X-Received: by 2002:aa7:c702:0:b0:461:8156:e0ca with SMTP id i2-20020aa7c702000000b004618156e0camr733214edq.271.1668159901827; Fri, 11 Nov 2022 01:45:01 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id f7-20020a1709063f4700b0078d0981516esm719419ejj.38.2022.11.11.01.45.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 01:45:01 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 800987A68A3; Fri, 11 Nov 2022 10:44:58 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Martin KaFai Lau In-Reply-To: References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-7-sdf@google.com> <187e89c3-d7de-7bec-c72e-d9d6eb5bcca0@linux.dev> <9a8fefe4-2fcb-95b7-cda0-06509feee78e@linux.dev> <6f57370f-7ec3-07dd-54df-04423cab6d1f@linux.dev> <87leokz8lq.fsf@toke.dk> <5a23b856-88a3-a57a-2191-b673f4160796@linux.dev> <871qqazyc9.fsf@toke.dk> <7eb3e22a-c416-e898-dff0-1146d3cc82c0@linux.dev> <87mt8yxuag.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 11 Nov 2022 10:44:58 +0100 Message-ID: <87iljl7rl1.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: IGNM6A2CTRHXOHA7AWP3RJL5PBKUVF25 X-Message-ID-Hash: IGNM6A2CTRHXOHA7AWP3RJL5PBKUVF25 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: Stanislav Fomichev , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, 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, bpf@vger.kernel.org X-Mailman-Version: 3.3.6 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 06/14] xdp: Carry over xdp metadata into skb context List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Martin KaFai Lau writes: > On 11/10/22 3:29 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>> For the metadata consumed by the stack right now it's a bit >>>> hypothetical, yeah. However, there's a bunch of metadata commonly >>>> supported by hardware that the stack currently doesn't consume and tha= t >>>> hopefully this feature will end up making more accessible. My hope is >>>> that the stack can also learn how to use this in the future, in which >>>> case we may run out of space. So I think of that bit mostly as >>>> future-proofing... >>> >>> ic. in this case, Can the btf_id be added to 'struct xdp_to_skb_metadat= a' later >>> if it is indeed needed? The 'struct xdp_to_skb_metadata' is not in UAP= I and >>> doing it with CO-RE is to give us flexibility to make this kind of chan= ges in >>> the future. >>=20 >> My worry is mostly that it'll be more painful to add it later than just >> including it from the start, mostly because of AF_XDP users. But if we >> do the randomisation thing (thus forcing AF_XDP users to deal with the >> dynamic layout as well), it should be possible to add it later, and I >> can live with that option as well... > > imo, considering we are trying to optimize unnecessary field > initialization as below, it is sort of wasteful to always initialize > the btf_id with the same value. It is better to add it in the future > when there is a need. Okay, let's omit the BTF ID for now, and see what that looks like. I'll try to keep in mind to see if I can find any reasons why we'd need to add it back and make sure to complain before this lands if I find any :) -Toke