From: Jakub Kicinski <kuba@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "Eric Dumazet" <edumazet@google.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Paolo Abeni" <pabeni@redhat.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Daniel Xu" <dxu@dxuuu.xyz>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
"Toke Høiland-Jørgensen" <toke@kernel.org>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 0/8] bpf: cpumap: enable GRO for XDP_PASS frames
Date: Wed, 12 Feb 2025 10:29:36 -0800 [thread overview]
Message-ID: <20250212102936.23617f03@kernel.org> (raw)
In-Reply-To: <1dd14ece-578b-4fe6-8ef1-557b0f5d3144@intel.com>
On Wed, 12 Feb 2025 16:55:52 +0100 Alexander Lobakin wrote:
> > You mean to cache napi_id in gro_node?
> >
> > Then we get +8 bytes to sizeof(napi_struct) for little reason...
Right but I think the expectation would be that we don't ever touch
that on the fast path, right? The "real" napi_id would basically
go down below:
/* control-path-only fields follow */
8B of cold data doesn't matter at all. But I haven't checked if
we need the napi->napi_id access anywhere hot, do we?
> > Dunno, if you really prefer, I can do it that way.
>
> Alternative to avoid +8 bytes:
>
> struct napi_struct {
> ...
>
> union {
> struct gro_node gro;
> struct {
> u8 pad[offsetof(struct gro_node, napi_id)];
> u32 napi_id;
> };
> };
>
> This is effectively the same what struct_group() does, just more ugly.
> But allows to declare gro_node separately.
next prev parent reply other threads:[~2025-02-12 18:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 16:36 [PATCH net-next v4 0/8] bpf: cpumap: enable GRO for XDP_PASS frames Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 1/8] net: gro: decouple GRO from the NAPI layer Alexander Lobakin
2025-02-05 17:48 ` Eric Dumazet
2025-02-06 2:56 ` Jakub Kicinski
2025-02-06 12:12 ` Alexander Lobakin
2025-02-06 18:35 ` Eric Dumazet
2025-02-07 11:56 ` Alexander Lobakin
2025-02-07 14:21 ` Przemek Kitszel
2025-02-07 14:55 ` Eric Dumazet
2025-02-07 15:18 ` Alexander Lobakin
2025-02-07 15:28 ` Eric Dumazet
2025-02-07 15:43 ` Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 2/8] net: gro: expose GRO init/cleanup to use outside of NAPI Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 3/8] bpf: cpumap: switch to GRO from netif_receive_skb_list() Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 4/8] bpf: cpumap: reuse skb array instead of a linked list to chain skbs Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 5/8] net: skbuff: introduce napi_skb_cache_get_bulk() Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 6/8] bpf: cpumap: switch to napi_skb_cache_get_bulk() Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 7/8] veth: use napi_skb_cache_get_bulk() instead of xdp_alloc_skb_bulk() Alexander Lobakin
2025-02-05 16:36 ` [PATCH net-next v4 8/8] xdp: remove xdp_alloc_skb_bulk() Alexander Lobakin
2025-02-10 14:05 ` [PATCH net-next v4 0/8] bpf: cpumap: enable GRO for XDP_PASS frames Alexander Lobakin
2025-02-10 15:31 ` Eric Dumazet
2025-02-10 15:31 ` Alexander Lobakin
2025-02-11 0:35 ` Jakub Kicinski
2025-02-12 14:22 ` Alexander Lobakin
2025-02-12 15:55 ` Alexander Lobakin
2025-02-12 18:29 ` Jakub Kicinski [this message]
2025-02-14 15:43 ` Alexander Lobakin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250212102936.23617f03@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dxu@dxuuu.xyz \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=toke@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).