From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by mail.toke.dk (Postfix) with ESMTPS id 36778A80E8B for ; Tue, 13 Aug 2024 03:33:14 +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=JNC79f9S Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 772D2CE113B; Tue, 13 Aug 2024 01:33:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB440C4AF0D; Tue, 13 Aug 2024 01:33:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723512789; bh=QnIqOdRlXgAHdeoAf7GYTXyIHrTOC2FQsadg/IU5oao=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JNC79f9SFF/uTToB2JU5w06EhaOeyvBP1g+a/QkZXX2U0zndkfsnqanPW1WnIOy7N pWjeXgr+S1MQ1I2CxuyT7h4MVKYWy1XkQIyYFkZbLcJgjVem9BBNE7hApxsUbyIW4D fotFmXmg0jMSQV3xTFvwDxwOFsCOEnqk9fKzDnjzuLhLmJD4drMzpg4SNxPqOtaq9x PZss4uxEzxQPR/zqAs/apU3pqdkhPMTQHUSv/Tq03DI6AXO6eqzVAC3/c/42rgWpzp G/FolFxrX4CGGBzSNe23OLdLUnyqEKQcDD61xkxxfO0bajuAd7AxN3WQT8yyd31864 EH8vANEWrqFmA== Date: Mon, 12 Aug 2024 18:33:07 -0700 From: Jakub Kicinski To: Alexander Lobakin Message-ID: <20240812183307.0b6fbd60@kernel.org> In-Reply-To: <99662019-7e9b-410d-99fe-a85d04af215c@intel.com> References: <20220628194812.1453059-1-alexandr.lobakin@intel.com> <20220628194812.1453059-33-alexandr.lobakin@intel.com> <54aab7ec-80e9-44fd-8249-fe0cabda0393@intel.com> <308fd4f1-83a9-4b74-a482-216c8211a028@app.fastmail.com> <99662019-7e9b-410d-99fe-a85d04af215c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MPIGN6Q3THMTS56BDOKXFCLXFLFDGJUO X-Message-ID-Hash: MPIGN6Q3THMTS56BDOKXFCLXFLFDGJUO 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: Daniel Xu , Lorenzo Bianconi , Alexander Lobakin , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Larysa Zaremba , Michal Swiatkowski , Jesper Dangaard Brouer , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "toke@redhat.com" , Lorenzo Bianconi , David Miller , Eric Dumazet , Paolo Abeni , Jesse Brandeburg , John Fastabend , Yajun Deng , Willem de Bruijn , "bpf@vger.kernel.org" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.9 Precedence: list Subject: [xdp-hints] Re: [PATCH RFC bpf-next 32/52] bpf, cpumap: switch to GRO from netif_receive_skb_list() List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 9 Aug 2024 14:20:25 +0200 Alexander Lobakin wrote: > But I think one solution could be: > > 1. We create some generic structure for cpumap, like > > struct cpumap_meta { > u32 magic; > u32 hash; > } > > 2. We add such check in the cpumap code > > if (xdpf->metalen == sizeof(struct cpumap_meta) && > ) > skb->hash = meta->hash; > > 3. In XDP prog, you call Rx hints kfuncs when they're available, obtain > RSS hash and then put it in the struct cpumap_meta as XDP frame metadata. I wonder what the overhead of skb metadata allocation is in practice. With Eric's "return skb to the CPU of origin" we can feed the lockless skb cache one the right CPU, and also feed the lockless page pool cache. I wonder if batched RFS wouldn't be faster than the XDP thing that requires all the groundwork.