From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by mail.toke.dk (Postfix) with ESMTPS id 2AAED9A855D for ; Thu, 6 Oct 2022 16:59:30 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=WTAnQ9CF Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4CCC6619EC; Thu, 6 Oct 2022 14:59:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24E10C433C1; Thu, 6 Oct 2022 14:59:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665068368; bh=DhoQTcRWD4rsk7jnT5ieI/JievE8tJN6SfZhhFrVZ94=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WTAnQ9CF5/E+L27yUFXDdfOXN4gUCmJ3JVgaCdDK5d3XXk8KV1zQOVxpQMal7SZfs IgJNUcrxhaHYtIInLLJwWFlh7Xrbs3fvw2qxsz7le+fjxt/FjslCZ6Iiw3Yfcg/Gwl byAqyeuSXECpq2Nd2o4Ex5SJxcKVbOVq3iZVtXHiFxO/ZawWyBJjHT67caKsy8JrDP x7R28HgrCRsNEdoE+6alxLpcSV6YCvbMrbKNbwnKKco3toeTaSUlZ6gQrUiZFopIIT 0XR9IBBpj5Tz75pF9Tj0eVJkE+wspN+WOVWf5ls6nI46SeTlYR0T6KHoUJuw/OvnoF LBu6zI4EmhRZA== Date: Thu, 6 Oct 2022 07:59:27 -0700 From: Jakub Kicinski To: Jesper Dangaard Brouer Message-ID: <20221006075927.39e43e6b@kernel.org> In-Reply-To: <55542209-03d7-590f-9ab1-bbbf924d033c@redhat.com> References: <166256538687.1434226.15760041133601409770.stgit@firesoul> <35fcfb25-583a-e923-6eee-e8bbcc19db17@redhat.com> <5ccff6fa-0d50-c436-b891-ab797fe7e3c4@linux.dev> <20221004175952.6e4aade7@kernel.org> <55542209-03d7-590f-9ab1-bbbf924d033c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: E2CJY3QQXAM3RBZP6LQYAADFRMF7PCDE X-Message-ID-Hash: E2CJY3QQXAM3RBZP6LQYAADFRMF7PCDE X-MailFrom: kuba@kernel.org 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 , brouer@redhat.com, Martin KaFai Lau , bpf@vger.kernel.org, netdev@vger.kernel.org, xdp-hints@xdp-project.net, larysa.zaremba@intel.com, memxor@gmail.com, Lorenzo Bianconi , mtahhan@redhat.com, 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 00/18] XDP-hints: XDP gaining access to HW offload hints via BTF List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, 5 Oct 2022 16:19:30 +0200 Jesper Dangaard Brouer wrote: > >> Since you mentioned it... FWIW that was always my preference rather than > >> the BTF magic :) The jited image would have to be per-driver like we > >> do for BPF offload but that's easy to do from the technical > >> perspective (I doubt many deployments bind the same prog to multiple > >> HW devices).. > > On the technical side we do have the ifindex that can be passed along > which is currently used for getting XDP hardware offloading to work. > But last time I tried this, I failed due to BPF tail call maps. FWIW the tail call map should be solvable by enforcing that the map is also pinned and so are all the programs in it. Perhaps I find that less ugly than others.. since that's what the offload path did :) > (It's not going to fly for other reasons, see redirect below).