[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231127190938.01005780@kernel.org>
Date: Mon, 27 Nov 2023 19:09:38 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Stanislav Fomichev <sdf@...gle.com>
Cc: 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, toke@...nel.org, willemb@...gle.com, dsahern@...nel.org,
magnus.karlsson@...el.com, bjorn@...nel.org, maciej.fijalkowski@...el.com,
hawk@...nel.org, yoong.siang.song@...el.com, netdev@...r.kernel.org,
xdp-hints@...-project.net
Subject: Re: [PATCH bpf-next v6 01/13] xsk: Support tx_metadata_len
On Mon, 27 Nov 2023 11:03:07 -0800 Stanislav Fomichev wrote:
> For zerocopy mode, tx_desc->addr can point to an arbitrary offset
> and carry some TX metadata in the headroom. For copy mode, there
> is no way currently to populate skb metadata.
>
> Introduce new tx_metadata_len umem config option that indicates how many
> bytes to treat as metadata. Metadata bytes come prior to tx_desc address
> (same as in RX case).
>
> The size of the metadata has mostly the same constraints as XDP:
> - less than 256 bytes
> - 8-byte aligned (compared to 4-byte alignment on xdp, due to 8-byte
> timestamp in the completion)
> - non-zero
>
> This data is not interpreted in any way right now.
Reviewed-by: Jakub Kicinski <kuba@...nel.org>
Powered by blists - more mailing lists