From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Magnus Karlsson" <magnus.karlsson@intel.com>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2 11/18] xdp: add generic xdp_buff_add_frag()
Date: Thu, 17 Oct 2024 14:26:48 +0200 [thread overview]
Message-ID: <ZxECiKa4a4LSq7zq@boxer> (raw)
In-Reply-To: <20241015145350.4077765-12-aleksander.lobakin@intel.com>
On Tue, Oct 15, 2024 at 04:53:43PM +0200, Alexander Lobakin wrote:
> The code piece which would attach a frag to &xdp_buff is almost
> identical across the drivers supporting XDP multi-buffer on Rx.
> Make it a generic elegant onelner.
oneliner
> Also, I see lots of drivers calculating frags_truesize as
> `xdp->frame_sz * nr_frags`. I can't say this is fully correct, since
> frags might be backed by chunks of different sizes, especially with
> stuff like the header split. Even page_pool_alloc() can give you two
> different truesizes on two subsequent requests to allocate the same
> buffer size. Add a field to &skb_shared_info (unionized as there's no
> free slot currently on x6_64) to track the "true" truesize. It can be
x86_64
> used later when updating an skb.
I also agree that xdp->frame_sz * nr_frags for truesize might be an
over-assumption.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
two small nits/questions below that might be ignored.
>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> include/linux/skbuff.h | 16 ++++++--
> include/net/xdp.h | 90 +++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 101 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index c867df5b1051..6ec78c1598fe 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -607,11 +607,19 @@ struct skb_shared_info {
> * Warning : all fields before dataref are cleared in __alloc_skb()
> */
> atomic_t dataref;
> - unsigned int xdp_frags_size;
>
> - /* Intermediate layers must ensure that destructor_arg
> - * remains valid until skb destructor */
> - void * destructor_arg;
> + union {
> + struct {
> + u32 xdp_frags_size;
> + u32 xdp_frags_truesize;
> + };
> +
> + /*
> + * Intermediate layers must ensure that destructor_arg
> + * remains valid until skb destructor.
> + */
> + void *destructor_arg;
> + };
>
> /* must be last field, see pskb_expand_head() */
> skb_frag_t frags[MAX_SKB_FRAGS];
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index c4b408d22669..19d2b283b845 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -167,6 +167,88 @@ xdp_get_buff_len(const struct xdp_buff *xdp)
> return len;
> }
>
> +/**
> + * __xdp_buff_add_frag - attach a frag to an &xdp_buff
> + * @xdp: XDP buffer to attach the frag to
> + * @page: page containing the frag
> + * @offset: page offset at which the frag starts
> + * @size: size of the frag
> + * @truesize: truesize (page / page frag size) of the frag
> + * @try_coalesce: whether to try coalescing the frags
> + *
> + * Attach a frag to an XDP buffer. If it currently has no frags attached,
> + * initialize the related fields, otherwise check that the frag number
> + * didn't reach the limit of ``MAX_SKB_FRAGS``. If possible, try coalescing
> + * the frag with the previous one.
> + * The function doesn't check/update the pfmemalloc bit. Please use the
> + * non-underscored wrapper in drivers.
> + *
> + * Return: true on success, false if there's no space for the frag in
> + * the shared info struct.
> + */
> +static inline bool __xdp_buff_add_frag(struct xdp_buff *xdp, struct page *page,
> + u32 offset, u32 size, u32 truesize,
> + bool try_coalesce)
> +{
> + struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
> + skb_frag_t *prev;
> + u32 nr_frags;
> +
> + if (!xdp_buff_has_frags(xdp)) {
> + xdp_buff_set_frags_flag(xdp);
> +
> + nr_frags = 0;
> + sinfo->xdp_frags_size = 0;
> + sinfo->xdp_frags_truesize = 0;
> +
> + goto fill;
> + }
> +
> + nr_frags = sinfo->nr_frags;
> + if (unlikely(nr_frags == MAX_SKB_FRAGS))
> + return false;
> +
> + prev = &sinfo->frags[nr_frags - 1];
> + if (try_coalesce && page == skb_frag_page(prev) &&
> + offset == skb_frag_off(prev) + skb_frag_size(prev))
> + skb_frag_size_add(prev, size);
> + else
> +fill:
> + __skb_fill_page_desc_noacc(sinfo, nr_frags++, page,
> + offset, size);
> +
> + sinfo->nr_frags = nr_frags;
is it really necessary to work on local nr_frags instead of directly
update it from sinfo?
> + sinfo->xdp_frags_size += size;
> + sinfo->xdp_frags_truesize += truesize;
> +
> + return true;
> +}
> +
> +/**
> + * xdp_buff_add_frag - attach a frag to an &xdp_buff
> + * @xdp: XDP buffer to attach the frag to
> + * @page: page containing the frag
> + * @offset: page offset at which the frag starts
> + * @size: size of the frag
> + * @truesize: truesize (page / page frag size) of the frag
> + *
> + * Version of __xdp_buff_add_frag() which takes care of the pfmemalloc bit.
> + *
> + * Return: true on success, false if there's no space for the frag in
> + * the shared info struct.
> + */
> +static inline bool xdp_buff_add_frag(struct xdp_buff *xdp, struct page *page,
> + u32 offset, u32 size, u32 truesize)
> +{
> + if (!__xdp_buff_add_frag(xdp, page, offset, size, truesize, true))
> + return false;
> +
> + if (unlikely(page_is_pfmemalloc(page)))
> + xdp_buff_set_frag_pfmemalloc(xdp);
> +
> + return true;
> +}
> +
> struct xdp_frame {
> void *data;
> u32 len;
> @@ -230,7 +312,13 @@ xdp_update_skb_shared_info(struct sk_buff *skb, u8 nr_frags,
> unsigned int size, unsigned int truesize,
> bool pfmemalloc)
> {
> - skb_shinfo(skb)->nr_frags = nr_frags;
> + struct skb_shared_info *sinfo = skb_shinfo(skb);
> +
> + sinfo->nr_frags = nr_frags;
> + /* ``destructor_arg`` is unionized with ``xdp_frags_{,true}size``,
> + * reset it after that these fields aren't used anymore.
> + */
> + sinfo->destructor_arg = NULL;
wouldn't clearing size and truesize from union be more obvious?
OTOH it's one write vs two :)
>
> skb->len += size;
> skb->data_len += size;
> --
> 2.46.2
>
next prev parent reply other threads:[~2024-10-17 12:27 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 14:53 [PATCH net-next v2 00/18] idpf: XDP chapter III: core XDP changes (+libeth_xdp) Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 01/18] jump_label: export static_key_slow_{inc,dec}_cpuslocked() Alexander Lobakin
2024-10-17 11:06 ` Maciej Fijalkowski
2024-10-21 13:53 ` Alexander Lobakin
2024-10-22 12:52 ` Maciej Fijalkowski
2024-10-15 14:53 ` [PATCH net-next v2 02/18] skbuff: allow 2-4-argument skb_frag_dma_map() Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 03/18] unroll: add generic loop unroll helpers Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 04/18] bpf, xdp: constify some bpf_prog * function arguments Alexander Lobakin
2024-10-17 11:12 ` Maciej Fijalkowski
2024-10-21 13:56 ` Alexander Lobakin
2024-10-22 12:55 ` Maciej Fijalkowski
2024-10-15 14:53 ` [PATCH net-next v2 05/18] xdp, xsk: constify read-only arguments of some static inline helpers Alexander Lobakin
2024-10-17 11:14 ` Maciej Fijalkowski
2024-10-21 13:57 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 06/18] xdp: allow attaching already registered memory model to xdp_rxq_info Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 07/18] net: Register system page pool as an XDP memory model Alexander Lobakin
2024-10-17 11:32 ` Maciej Fijalkowski
2024-10-21 14:00 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 08/18] page_pool: make page_pool_put_page_bulk() actually handle array of pages Alexander Lobakin
2024-10-17 11:33 ` Maciej Fijalkowski
2024-10-21 14:03 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 09/18] page_pool: allow mixing PPs within one bulk Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 10/18] xdp: get rid of xdp_frame::mem.id Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 11/18] xdp: add generic xdp_buff_add_frag() Alexander Lobakin
2024-10-17 12:26 ` Maciej Fijalkowski [this message]
2024-10-21 14:10 ` Alexander Lobakin
2024-10-22 13:00 ` Maciej Fijalkowski
2024-10-15 14:53 ` [PATCH net-next v2 12/18] xdp: add generic xdp_build_skb_from_buff() Alexander Lobakin
2024-10-17 12:34 ` Maciej Fijalkowski
2024-10-21 14:20 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 13/18] xsk: allow attaching XSk pool via xdp_rxq_info_reg_mem_model() Alexander Lobakin
2024-10-17 12:49 ` Maciej Fijalkowski
2024-10-21 14:23 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 14/18] xsk: make xsk_buff_add_frag really add a frag via __xdp_buff_add_frag() Alexander Lobakin
2024-10-17 13:04 ` Maciej Fijalkowski
2024-10-15 14:53 ` [PATCH net-next v2 15/18] xsk: add generic XSk &xdp_buff -> skb conversion Alexander Lobakin
2024-10-18 12:48 ` Maciej Fijalkowski
2024-10-15 14:53 ` [PATCH net-next v2 16/18] xsk: add helper to get &xdp_desc's DMA and meta pointer in one go Alexander Lobakin
2024-10-22 15:42 ` Maciej Fijalkowski
2024-10-23 14:50 ` Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 17/18] libeth: support native XDP and register memory model Alexander Lobakin
2024-10-15 14:53 ` [PATCH net-next v2 18/18] libeth: add a couple of XDP helpers (libeth_xdp) 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=ZxECiKa4a4LSq7zq@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=toke@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.