linux-kernel - Re: [xdp-hints] Re: [PATCH RFC bpf-next 32/52] bpf, cpumap: switch to GRO from netif_receive_skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240812183307.0b6fbd60@kernel.org>
Date: Mon, 12 Aug 2024 18:33:07 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: Daniel Xu <dxu@...uu.xyz>, Lorenzo Bianconi
 <lorenzo.bianconi@...hat.com>, Alexander Lobakin
 <alexandr.lobakin@...el.com>, Alexei Starovoitov <ast@...nel.org>, "Daniel
 Borkmann" <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
 Larysa Zaremba <larysa.zaremba@...el.com>, Michal Swiatkowski
 <michal.swiatkowski@...ux.intel.com>, Jesper Dangaard Brouer
 <hawk@...nel.org>, Björn Töpel <bjorn@...nel.org>,
 Magnus Karlsson <magnus.karlsson@...el.com>, Maciej Fijalkowski
 <maciej.fijalkowski@...el.com>, Jonathan Lemon <jonathan.lemon@...il.com>,
 "toke@...hat.com" <toke@...hat.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, "Jesse Brandeburg"
 <jesse.brandeburg@...el.com>, John Fastabend <john.fastabend@...il.com>,
 Yajun Deng <yajun.deng@...ux.dev>, "Willem de Bruijn" <willemb@...gle.com>,
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>, <netdev@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <xdp-hints@...-project.net>
Subject: Re: [xdp-hints] Re: [PATCH RFC bpf-next 32/52] bpf, cpumap: switch
 to GRO from netif_receive_skb_list()

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) &&
> 	    <here we check magic>)
> 		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.