From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mail.toke.dk (Postfix) with ESMTPS id 6705A851E4B for ; Fri, 28 May 2021 11:16:54 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Knomo7GU DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622193410; 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=UqGUmWxUI1aVI5m8Eebociw05Yq3S7eC/phq5U0Gnwg=; b=Knomo7GU8ff6nKxUb5RY7ohiUaYcwC4kw7OX1wGlEsmGEWul7z2cCQ2Z91FMp+63agZcjM qvvT7fD3yvbuenKZhXz/pLj9X2GJI8Uw4gLl5q+HjWne1SnwaWXJSXMbn/t2AcXAwNPtNI RhvcxM58WXhNzTCIcVyLA5yu2+Nju+E= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-303-H93tDk9XNhavoEr36eOeNw-1; Fri, 28 May 2021 05:16:48 -0400 X-MC-Unique: H93tDk9XNhavoEr36eOeNw-1 Received: by mail-ed1-f72.google.com with SMTP id cn20-20020a0564020cb4b029038d0b0e183fso1801291edb.22 for ; Fri, 28 May 2021 02:16:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=UqGUmWxUI1aVI5m8Eebociw05Yq3S7eC/phq5U0Gnwg=; b=uEEEOh/FPxc1fFNytHNG6+hAHy8sJFJDG8rg9dAkzo0LFOE3LSYWWqbA8/kFbg+kO4 riJt+/bK7uUKlkMYFjSD0BRdc7bUZE6ICEyzHybz4+ez+Ukfwa3Q7iUGaEq8m3IbTiKZ pqzxml3QTNpUGQ0eNq7bQG49/E0eSfG9Hzlkv9q601gHBj7F+7dlfzDDnphXAsaEo7EI AEiUFtO63Z1v7lsK/A49K3zUkTUHgls6/WFbzXccXCa6kDN5XvZjfZiWdHRTCQHKK+G3 oSdtu8PQkOj0AGvvVv67FWNhpdDryRW7Y6ELPozslmUs9RL2FVW8pSYNK66dwO8+BgW2 Nl1w== X-Gm-Message-State: AOAM531JidJdO4sGvNVJtQCBxbBJUqJUSG01MezNHr80t4TuAwIjQyha qwoTIOkBfcwnXsitzoi2lhh+8BuM/bTbJ0rQwJe9PM3M2Afwg5BvY66UBeu2vI3UQl+c/F5PbXq E1xYAPtMZODDTAbSESUeD X-Received: by 2002:a05:6402:30a2:: with SMTP id df2mr8645730edb.176.1622193407545; Fri, 28 May 2021 02:16:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGlmB+oEv2RNwrXsHFQ9SdYfIMnO6kYtfXRBZGswyCoGcJyrcrmHh3eFfkFWx6o+d7W/M20w== X-Received: by 2002:a05:6402:30a2:: with SMTP id df2mr8645678edb.176.1622193407129; Fri, 28 May 2021 02:16:47 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id j4sm2381592edq.13.2021.05.28.02.16.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 02:16:46 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id B44AD18071B; Fri, 28 May 2021 11:16:44 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: John Fastabend , Andrii Nakryiko , John Fastabend Subject: Re: XDP-hints: Howto support multiple BTF types per packet basis? In-Reply-To: <60b08442b18d5_1cf8208a0@john-XPS-13-9370.notmuch> References: <20210526125848.1c7adbb0@carbon> <60aeb01ebcd10_fe49208b8@john-XPS-13-9370.notmuch> <60aeeb5252147_19a622085a@john-XPS-13-9370.notmuch> <60b08442b18d5_1cf8208a0@john-XPS-13-9370.notmuch> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 28 May 2021 11:16:44 +0200 Message-ID: <87fsy7gqv7.fsf@toke.dk> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=toke@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: AOBORF6Q4EMJM4E2MPITF7N5H4F6YCTR X-Message-ID-Hash: AOBORF6Q4EMJM4E2MPITF7N5H4F6YCTR 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: Jesper Dangaard Brouer , BPF-dev-list , Alexander Lobakin , "Karlsson, Magnus" , Magnus Karlsson , David Ahern , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , Saeed Mahameed , "kurt@linutronix.de" , "Raczynski, Piotr" , "Zhang, Jessica" , "Maloor, Kishen" , "Gomes, Vinicius" , "Brandeburg, Jesse" , "Swiatkowski, Michal" , "Plantykow, Marta A" , "Desouza, Ederson" , "Song, Yoong Siang" , "Czapnik, Lukasz" , "Joseph, Jithu" , William Tu , Ong Boon Leong , xdp-hints@xdp-project.net X-Mailman-Version: 3.3.4 Precedence: list List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: John Fastabend writes: >> > > union and independent set of BTFs are two different things, I'll let >> > > you guys figure out which one you need, but I replied how it could >> > > look like in CO-RE world >> > >> > I think a union is sufficient and more aligned with how the >> > hardware would actually work. >> >> Sure. And I think those are two orthogonal concerns. You can start >> with a single struct mynic_metadata with union inside it, and later >> add the ability to swap mynic_metadata with another >> mynic_metadata___v2 that will have a similar union but with a >> different layout. > > Right and then you just have normal upgrade/downgrade problems with > any struct. > > Seems like a workable path to me. But, need to circle back to the > what we want to do with it part that Jesper replied to. So while this seems to be a viable path for getting libbpf to do all the relocations (and thanks for hashing that out, I did not have a good grip of the details), doing it all in userspace means that there is no way for the XDP program to react to changes once it has been loaded. So this leaves us with a selection of non-very-attractive options, IMO. I.e., we would have to: - have to block any modifications to the hardware config that would change the metadata format; this will probably result in irate users - require XDP programs to deal with all possible metadata permutations supported by that driver (by exporting them all via a BTF union or similar); this means a potential for combinatorial explosion of config options and as NICs become programmable themselves I'm not even sure if it's possible for the driver to know ahead of time - throw up our hands and just let the user deal with it (i.e., to nothing and so require XDP programs to be reloaded if the NIC config changes); this is not very friendly and is likely to lead to subtle bugs if an XDP program parses the metadata assuming it is in a different format than it is Given that hardware config changes are not just done by ethtool, but also by things like running `tcpdump -j`, I really think we have to assume that they can be quite dynamic; which IMO means we have to solve this as part of the initial design. And I have a hard time seeing how this is possible without involving the kernel somehow. Unless I'm missing something? WDYT? -Toke