[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87edts2z8n.fsf@toke.dk>
Date: Thu, 24 Nov 2022 15:39:20 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: sdf@...gle.com, bpf@...r.kernel.org, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
song@...nel.org, yhs@...com, john.fastabend@...il.com,
kpsingh@...nel.org, haoluo@...gle.com, jolsa@...nel.org,
Tariq Toukan <tariqt@...dia.com>,
David Ahern <dsahern@...il.com>,
Willem de Bruijn <willemb@...gle.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Anatoly Burakov <anatoly.burakov@...el.com>,
Alexander Lobakin <alexandr.lobakin@...el.com>,
Magnus Karlsson <magnus.karlsson@...il.com>,
Maryam Tahhan <mtahhan@...hat.com>, xdp-hints@...-project.net,
netdev@...r.kernel.org
Subject: Re: [xdp-hints] Re: [PATCH bpf-next v2 6/8] mlx4: Introduce
mlx4_xdp_buff wrapper for xdp_buff
Jakub Kicinski <kuba@...nel.org> writes:
> On Wed, 23 Nov 2022 22:55:21 +0100 Toke Høiland-Jørgensen wrote:
>> > Good idea, prototyped below, lmk if it that's not what you had in mind.
>> >
>> > struct xdp_buff_xsk {
>> > struct xdp_buff xdp; /* 0 56 */
>> > u8 cb[16]; /* 56 16 */
>> > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
>>
>> As pahole helpfully says here, xdp_buff is actually only 8 bytes from
>> being a full cache line. I thought about adding a 'cb' field like this
>> to xdp_buff itself, but figured that since there's only room for a
>> single pointer, why not just add that and let the driver point it to
>> where it wants to store the extra context data?
>
> What if the driver wants to store multiple pointers or an integer or
> whatever else? The single pointer seems quite arbitrary and not
> strictly necessary.
Well, then you allocate a separate struct and point to that? Like I did
in mlx5:
+ struct mlx5_xdp_ctx mlctx = { .cqe = cqe, .rq = rq };
+ struct xdp_buff xdp = { .drv_priv = &mlctx };
but yeah, this does give an extra pointer deref on access. I'm not
really opposed to the cb field either, I just think it's a bit odd to
put it in struct xdp_buff_xsk; that basically requires the driver to
keep the layouts in sync.
Instead, why not but a cb field into xdp_buff itself so it can be used
for both the XSK and the non-XSK paths? Then the driver can just
typecast the xdp_buff into its own struct that has whatever data it
wants in place of the cb field?
-Toke
Powered by blists - more mailing lists