From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by mail.toke.dk (Postfix) with ESMTPS id 61A4C85AA36 for ; Thu, 24 Jun 2021 16:59:10 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=OuLfJ5S9 Received: by mail-lj1-x229.google.com with SMTP id u20so8112344ljl.13 for ; Thu, 24 Jun 2021 07:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A5Af/F0RmtdZJaaM4A4ftcPZxj+C6ieZjclwoHh13Kc=; b=OuLfJ5S9M+bTjtperCT65qqeQPvaGLoy+V1ScPqwnNLlhwt60KifDTIKRoj2MWlCZC 4bEAw3HBog77tcChDUcb+2tFVBH8lW5D4O2j3VvMEOnRDEwvkbD5iU7nC9A1ZeFuQn0B kQKF9xuo+bod0cz/YuL4a0k9N42gfhjG5dXMM/i1LgqveSPzbfbpFGYu7RCWqlKxiVdo +1tGsJKH4+s0v2VkXvvFKkdM+iM36KiL1EwkQJBdA7AaOfs8z1Ob8iFx7OqR4YL0JJk+ lKjrVh5ctZPVfaP9KK8anFuiMiTt5Aw759y7fL2IksZnQ1Ou3UPITDP9ctoaB5NL4hCr QxbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A5Af/F0RmtdZJaaM4A4ftcPZxj+C6ieZjclwoHh13Kc=; b=hylSULuWwxTY9/gDGtm0KYq3Prb/l/sXldqEmtvgGsPaqz8m0cKPx5BePWq4kv7o1m yrNdmKsinL6bbbF0tbO/2/t8rR8jZtq9f5spQq+7847FMeWrE1XQcJoztRbw3JHOyDwY jQht46l02LimmquiipKY2wf10wIemB2wPUDQ3MYBAvsdQx62F8IIv0TlxHvPz1xhdb4J 5AVodlIoLJXFkUFN4VUEV5uaf9ozzaPwMUup0gETfs8g7GOiQ+ayuodR4FQ/OXAuVpXw shc4J0bWjedMxpbDRCaYl7G/50SwSotuoRjC3r9Qw4VaFcqK3fIXdPoz6s8mSAQYznv6 wHlA== X-Gm-Message-State: AOAM532Nh449NNlNgf3sQoqHR1wGrEJ9SiHklxzkOU/U3zH8I1sU7kp4 X0OPbFgfyUl/GlORoZfpL+I5KUqwaFmPTJcsxcQ= X-Google-Smtp-Source: ABdhPJyZkIOCJcRLz8nrja7NxQQjXYNsSXh9Q8wMc5WcrbysCtMkIwW+EC3NM42TRtoM1Z7nBnb637HVIN3Jh8azfCI= X-Received: by 2002:a2e:7e0e:: with SMTP id z14mr4355228ljc.21.1624546747262; Thu, 24 Jun 2021 07:59:07 -0700 (PDT) MIME-Version: 1.0 References: <60b08442b18d5_1cf8208a0@john-XPS-13-9370.notmuch> <87fsy7gqv7.fsf@toke.dk> <60b0ffb63a21a_1cf82089e@john-XPS-13-9370.notmuch> <20210528180214.3b427837@carbon> <60b12897d2e3f_1cf820896@john-XPS-13-9370.notmuch> <8735u3dv2l.fsf@toke.dk> <60b6cf5b6505e_38d6d208d8@john-XPS-13-9370.notmuch> <20210602091837.65ec197a@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net> <874kdqqfnm.fsf@toke.dk> <87mtrfmoyh.fsf@toke.dk> In-Reply-To: From: Alexei Starovoitov Date: Thu, 24 Jun 2021 07:58:55 -0700 Message-ID: Subject: Re: XDP-hints: Howto support multiple BTF types per packet basis? To: Magnus Karlsson Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: IKF6RL42EVUM3SFCFUTZ46SNAPJAOUXB X-Message-ID-Hash: IKF6RL42EVUM3SFCFUTZ46SNAPJAOUXB X-MailFrom: alexei.starovoitov@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: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Michal Swiatkowski , Jakub Kicinski , John Fastabend , Jesper Dangaard Brouer , Andrii Nakryiko , BPF-dev-list , William Tu , 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: On Thu, Jun 24, 2021 at 6:08 AM Magnus Karlsson wrote: > > > > and libbpf could do relocations based on the different meta structs, > > even removing the code for the ones that don't exist on the running > > kernel. > > Just wondering how this will carry over to user-space and AF_XDP since > it sees the same metadata area as XDP? AFAIK, dynamic linkers today > cannot relocate structs or remove members, but I am not up-to-date > with the latest here so might be completely wrong. And it would be > good not to have to recompile a user-space binary just because a new > NIC came out with a new BTF ID and layout, but with the same metadata > member name and format as previous NICs/BTF IDs. But I do not know how > to solve these things in user-space at the moment (except to have > fixed locations for a common set of metadata, but that is what we are > trying to avoid), so any hints and suggestions are highly appreciated. CO-RE is not a kernel only feature. The BTF tests in selftest/bpf exercise most of CO-RE purely in user space. The libbpf needs to know the original BTF and the target BTF to match one to another. One option for AF_XDP would be to write a bpf program to be run in user space and let libbpf handle relocations. Another option is to teach llvm x86 backend to support __attribute__((preserve_access_index)). The work done by llvm BPF backend can be copy pasted to x86 backend. Then standard x86 binaries will support dynamic struct layout. imo CO-RE for x86 backend would be great to do regardless of xdp hints. It's a straightforward copy-paste. Only need to convince x86 llvm maintainers.