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.133.124]) by mail.toke.dk (Postfix) with ESMTPS id 38D8C8BBBC7 for ; Mon, 13 Sep 2021 13:35:12 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=e/6Oaj/X DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631532910; 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; bh=DWjMjXt3tKXT9y7/famTmIP//AvnKcUJfDsY/114QRY=; b=e/6Oaj/Xh4fWgmMXglHxD9aVg7+OF0Xhi2GuXHkKeJ9mx7G9FskI9zI0k9m6ELjvAksndU hv8xkObbx9xjES7gC5jluuH617z0Ulgfy91Wrs7mMay4FD3BgJHTJbMqlMRZ74rHNTm1wr I7//5eJzTNeHmCS806qBA4gzOmxaQY4= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-526-Nq7NkgCPPyqLSlDxuohMKw-1; Mon, 13 Sep 2021 07:35:08 -0400 X-MC-Unique: Nq7NkgCPPyqLSlDxuohMKw-1 Received: by mail-lf1-f71.google.com with SMTP id g9-20020a0565123b8900b003f33a027130so897116lfv.18 for ; Mon, 13 Sep 2021 04:35:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:cc:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=DWjMjXt3tKXT9y7/famTmIP//AvnKcUJfDsY/114QRY=; b=gZi4eoJZc/eGQbtPxyPg8Cuh1nzZ+WXJZwtPS0UZsBiHORShHBenWX40JBLexMsc1F 3HgWjEL+NnSzQ+HxEzv3Jh4WbrVUFowFfINsa9BSoV0XkWcKt3a9Z22nGuWnnr6qNGks iE8AHpSz6nMA3t3j7+h/2zQxQtn8jXPkjzzAMeTNO96HIVRfhHyY1Jpoml4Whzis23Ij yN/FW7QVLYKyEi4E6+6ZFW1qlLAXIWgydyoWAokx5XiNCfIOGESBcy53IVpImlNJ4hhn uSaGN8upRf25OAca6pXTaapD/koIzH4eZvCw2im7czsARUbDyWenRnBtsvUEK2UCFLiR aBrA== X-Gm-Message-State: AOAM531Oisaf4KLwcWobZvgIN/Z7GslQEgGa70WS6AcP1x6Rn4IwOJoR mTYcNM+e2GQ4NJ4+EwFbPRUd6fSMzJHCj+4ix5DN/BL74UjVN48b3wmB3XLzzYSvWYqRYYB4yfy lkRQQ3nbyuLFRmXZi4SO+ X-Received: by 2002:ac2:5ded:: with SMTP id z13mr8793128lfq.428.1631532907006; Mon, 13 Sep 2021 04:35:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXewiNcd/iT983C4OrQ+1fTOhPFXrpuV3hE6k2dPYw/EE3yDUKBt/f1n56/OZuJVHfFyKbHQ== X-Received: by 2002:ac2:5ded:: with SMTP id z13mr8793103lfq.428.1631532906723; Mon, 13 Sep 2021 04:35:06 -0700 (PDT) Received: from [192.168.42.238] (87-59-106-155-cable.dk.customer.tdc.net. [87.59.106.155]) by smtp.gmail.com with ESMTPSA id n25sm949531ljj.42.2021.09.13.04.35.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 04:35:06 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer To: Andrii Nakryiko , Michal Swiatkowski , "Desouza, Ederson" , Alexander Lobakin Subject: XDP-hints as BTF early design discussion phase Message-ID: <6850bdde-b660-5ed3-9749-2fc6c1c1d0b7@redhat.com> Date: Mon, 13 Sep 2021 13:35:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jbrouer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-ID-Hash: QX7REPV5EC66AP4YCCGT6PJTB23N2KT4 X-Message-ID-Hash: QX7REPV5EC66AP4YCCGT6PJTB23N2KT4 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, "xdp-hints@xdp-project.net" , bpf , Alexei Starovoitov , Toke Hoiland Jorgensen , John Fastabend 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: Trying to get started with XDP-hints again. The fundamental idea is that XDP-hints metadata struct's are defined by the kernel, preferably by the kernel module, and described via BTF. As BTF layout is defined by kernel, this means userspace (AF_XDP) and BPF-progs must adapt to layout (used by running kernel). This imply that kernel is free to change layout. The BTF ID is exposed (to BPF-prog and AF_XDP) on per packet basis, to give kernel more freedom to change layout runtime. This push responsibility to userspace/BPF-prog of handling different layouts, which seems natural. For the kernel this solves many issues around concurrency and NIC config changes that affects BTF info available (e.g. when BTF layout is allowed to change). End-goal is to make it easier for kernel drivers can invent new layouts to suite new hardware features. Thus, we prefer a solution where XDP-hints metadata struct's are defined in the kernel module code. (Idea below ... please let us know what you think, wrong direction?) Exploring kernel module code defining the XDP-hints metadata struct. Kernel module BTFs are now[1][2] exposed through sysfs as /sys/kernel/btf/. Thus, userspace can use libbpf btf__load_module_btf() and others BTF APIs. Started playing here[3]. Credit to Toke, who had an idea that drivers could "say" what struct's are available, by defining a union with a known name e.g. metadata_hints_avail' and have supported metadata struct's included in that union. Then we don't need new APIs for exporting these BTF-metadata struct's. To find struct names, we BTF walk this union. -Jesper [1] https://lore.kernel.org/bpf/20201110011932.3201430-5-andrii@kernel.org/ [2] 36e68442d1af ("bpf: Load and verify kernel module BTFs") (Author: Andrii Nakryiko) [3] https://github.com/xdp-project/bpf-examples/blob/master/BTF-playground/