From: Yunsheng Lin <linyunsheng@huawei.com>
To: Matteo Croce <mcroce@linux.microsoft.com>,
<netdev@vger.kernel.org>, <linux-mm@kvack.org>
Cc: Ayush Sawal <ayush.sawal@chelsio.com>,
Vinay Kumar Yadav <vinay.yadav@chelsio.com>,
Rohit Maheshwari <rohitm@chelsio.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
Marcin Wojtas <mw@semihalf.com>,
Russell King <linux@armlinux.org.uk>,
Mirko Lindner <mlindner@marvell.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Tariq Toukan <tariqt@nvidia.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Boris Pismenny <borisp@nvidia.com>, Arnd Bergmann <arnd@arndb.de>,
Andrew Morton <akpm@linux-foundation.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Vlastimil Babka <vbabka@suse.cz>, Yu Zhao <yuzhao@google.com>,
Will Deacon <will@kernel.org>, Fenghua Yu <fenghua.yu@intel.com>,
Roman Gushchin <guro@fb.com>, Hugh Dickins <hughd@google.com>,
Peter Xu <peterx@redhat.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Alexander Lobakin <alobakin@pm.me>,
Cong Wang <cong.wang@bytedance.com>, wenxu <wenxu@ucloud.cn>,
Kevin Hao <haokexin@gmail.com>,
Jakub Sitnicki <jakub@cloudflare.com>,
Marco Elver <elver@google.com>,
Willem de Bruijn <willemb@google.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Guillaume Nault <gnault@redhat.com>,
<linux-kernel@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<bpf@vger.kernel.org>, Matthew Wilcox <willy@infradead.org>,
Eric Dumazet <edumazet@google.com>,
David Ahern <dsahern@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>, Andrew Lunn <andrew@lunn.ch>,
Paolo Abeni <pabeni@redhat.com>,
Sven Auhagen <sven.auhagen@voleatech.de>
Subject: Re: [PATCH net-next v6 3/5] page_pool: Allow drivers to hint on SKB recycling
Date: Fri, 4 Jun 2021 15:52:59 +0800 [thread overview]
Message-ID: <badedf51-ce74-061d-732c-61d0678180b3@huawei.com> (raw)
In-Reply-To: <20210521161527.34607-4-mcroce@linux.microsoft.com>
On 2021/5/22 0:15, Matteo Croce wrote:
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>
> Up to now several high speed NICs have custom mechanisms of recycling
> the allocated memory they use for their payloads.
> Our page_pool API already has recycling capabilities that are always
> used when we are running in 'XDP mode'. So let's tweak the API and the
> kernel network stack slightly and allow the recycling to happen even
> during the standard operation.
> The API doesn't take into account 'split page' policies used by those
> drivers currently, but can be extended once we have users for that.
>
> The idea is to be able to intercept the packet on skb_release_data().
> If it's a buffer coming from our page_pool API recycle it back to the
> pool for further usage or just release the packet entirely.
>
> To achieve that we introduce a bit in struct sk_buff (pp_recycle:1) and
> a field in struct page (page->pp) to store the page_pool pointer.
> Storing the information in page->pp allows us to recycle both SKBs and
> their fragments.
> We could have skipped the skb bit entirely, since identical information
> can bederived from struct page. However, in an effort to affect the free path
> as less as possible, reading a single bit in the skb which is already
> in cache, is better that trying to derive identical information for the
> page stored data.
>
> The driver or page_pool has to take care of the sync operations on it's own
> during the buffer recycling since the buffer is, after opting-in to the
> recycling, never unmapped.
>
> Since the gain on the drivers depends on the architecture, we are not
> enabling recycling by default if the page_pool API is used on a driver.
> In order to enable recycling the driver must call skb_mark_for_recycle()
> to store the information we need for recycling in page->pp and
> enabling the recycling bit, or page_pool_store_mem_info() for a fragment.
The state of this patch in patchwork is "Not Applicable", so
you may need to respin it again.
Some minor comment below:
>
> Co-developed-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Co-developed-by: Matteo Croce <mcroce@microsoft.com>
> Signed-off-by: Matteo Croce <mcroce@microsoft.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
> include/linux/skbuff.h | 28 +++++++++++++++++++++++++---
> include/net/page_pool.h | 9 +++++++++
> net/core/page_pool.c | 23 +++++++++++++++++++++++
> net/core/skbuff.c | 24 ++++++++++++++++++++----
> 4 files changed, 77 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 7fcfea7e7b21..057b40ad29bd 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -40,6 +40,9 @@
> #if IS_ENABLED(CONFIG_NF_CONNTRACK)
> #include <linux/netfilter/nf_conntrack_common.h>
> #endif
> +#ifdef CONFIG_PAGE_POOL
> +#include <net/page_pool.h>
> +#endif
>
> /* The interface for checksum offload between the stack and networking drivers
> * is as follows...
> @@ -667,6 +670,8 @@ typedef unsigned char *sk_buff_data_t;
> * @head_frag: skb was allocated from page fragments,
> * not allocated by kmalloc() or vmalloc().
> * @pfmemalloc: skbuff was allocated from PFMEMALLOC reserves
> + * @pp_recycle: mark the packet for recycling instead of freeing (implies
> + * page_pool support on driver)
> * @active_extensions: active extensions (skb_ext_id types)
> * @ndisc_nodetype: router type (from link layer)
> * @ooo_okay: allow the mapping of a socket to a queue to be changed
> @@ -791,10 +796,12 @@ struct sk_buff {
> fclone:2,
> peeked:1,
> head_frag:1,
> - pfmemalloc:1;
> + pfmemalloc:1,
> + pp_recycle:1; /* page_pool recycle indicator */
The about comment seems unnecessary, for there is comment
added above in this patch to explain that.
> #ifdef CONFIG_SKB_EXTENSIONS
> __u8 active_extensions;
> #endif
> +
Unnecessary change?
> /* fields enclosed in headers_start/headers_end are copied
> * using a single memcpy() in __copy_skb_header()
> */
> @@ -3088,7 +3095,13 @@ static inline void skb_frag_ref(struct sk_buff *skb, int f)
> */
> static inline void __skb_frag_unref(skb_frag_t *frag, bool recycle)
> {
> - put_page(skb_frag_page(frag));
> + struct page *page = skb_frag_page(frag);
> +
> +#ifdef CONFIG_PAGE_POOL
> + if (recycle && page_pool_return_skb_page(page_address(page)))
> + return;
> +#endif
> + put_page(page);
> }
>
> /**
> @@ -3100,7 +3113,7 @@ static inline void __skb_frag_unref(skb_frag_t *frag, bool recycle)
> */
> static inline void skb_frag_unref(struct sk_buff *skb, int f)
> {
> - __skb_frag_unref(&skb_shinfo(skb)->frags[f], false);
> + __skb_frag_unref(&skb_shinfo(skb)->frags[f], skb->pp_recycle);
> }
>
> /**
> @@ -4699,5 +4712,14 @@ static inline u64 skb_get_kcov_handle(struct sk_buff *skb)
> #endif
> }
>
> +#ifdef CONFIG_PAGE_POOL
> +static inline void skb_mark_for_recycle(struct sk_buff *skb, struct page *page,
> + struct page_pool *pp)
> +{
> + skb->pp_recycle = 1;
> + page_pool_store_mem_info(page, pp);
> +}
> +#endif
> +
> #endif /* __KERNEL__ */
> #endif /* _LINUX_SKBUFF_H */
> diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> index b4b6de909c93..7b9b6a1c61f5 100644
> --- a/include/net/page_pool.h
> +++ b/include/net/page_pool.h
> @@ -146,6 +146,8 @@ inline enum dma_data_direction page_pool_get_dma_dir(struct page_pool *pool)
> return pool->p.dma_dir;
> }
>
> +bool page_pool_return_skb_page(void *data);
> +
> struct page_pool *page_pool_create(const struct page_pool_params *params);
>
> #ifdef CONFIG_PAGE_POOL
> @@ -251,4 +253,11 @@ static inline void page_pool_ring_unlock(struct page_pool *pool)
> spin_unlock_bh(&pool->ring.producer_lock);
> }
>
> +/* Store mem_info on struct page and use it while recycling skb frags */
> +static inline
> +void page_pool_store_mem_info(struct page *page, struct page_pool *pp)
The conventional practice seems to put "struct page_pool" before other
parameter in page_pool.h.
> +{
> + page->pp = pp;
> +}
> +
> #endif /* _NET_PAGE_POOL_H */
> diff --git a/net/core/page_pool.c b/net/core/page_pool.c
> index e1321bc9d316..2a020cca489f 100644
> --- a/net/core/page_pool.c
> +++ b/net/core/page_pool.c
> @@ -628,3 +628,26 @@ void page_pool_update_nid(struct page_pool *pool, int new_nid)
> }
> }
> EXPORT_SYMBOL(page_pool_update_nid);
> +
> +bool page_pool_return_skb_page(void *data)
> +{
> + struct page_pool *pp;
> + struct page *page;
> +
> + page = virt_to_head_page(data);
> + if (unlikely(page->pp_magic != PP_SIGNATURE))
> + return false;
> +
> + pp = (struct page_pool *)page->pp;
> +
> + /* Driver set this to memory recycling info. Reset it on recycle.
> + * This will *not* work for NIC using a split-page memory model.
> + * The page will be returned to the pool here regardless of the
> + * 'flipped' fragment being in use or not.
> + */
I am not sure I understand how does the last part of comment related
to the code below, as there is no driver using split-page memory model
will reach here because those driver will not call skb_mark_for_recycle(),
right?
> + page->pp = NULL;
> + page_pool_put_full_page(pp, virt_to_head_page(data), false);
> +
> + return true;
> +}
> +EXPORT_SYMBOL(page_pool_return_skb_page);
next prev parent reply other threads:[~2021-06-04 7:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 16:15 [PATCH net-next v6 0/5] page_pool: recycle buffers Matteo Croce
2021-05-21 16:15 ` [PATCH net-next v6 1/5] mm: add a signature in struct page Matteo Croce
2021-05-21 16:15 ` [PATCH net-next v6 2/5] skbuff: add a parameter to __skb_frag_unref Matteo Croce
2021-05-21 16:15 ` [PATCH net-next v6 3/5] page_pool: Allow drivers to hint on SKB recycling Matteo Croce
2021-06-03 18:45 ` Matteo Croce
2021-06-04 7:52 ` Yunsheng Lin [this message]
2021-06-04 8:42 ` Ilias Apalodimas
2021-06-05 16:06 ` David Ahern
2021-06-05 16:34 ` Matteo Croce
2021-06-06 13:56 ` Tariq Toukan
2021-06-07 4:38 ` Ilias Apalodimas
2021-06-07 11:14 ` Tariq Toukan
2021-06-07 4:35 ` Ilias Apalodimas
2021-05-21 16:15 ` [PATCH net-next v6 4/5] mvpp2: recycle buffers Matteo Croce
2021-05-21 16:15 ` [PATCH net-next v6 5/5] mvneta: " Matteo Croce
2021-05-28 0:44 ` [PATCH net-next v6 0/5] page_pool: " Matteo Croce
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=badedf51-ce74-061d-732c-61d0678180b3@huawei.com \
--to=linyunsheng@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alobakin@pm.me \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=ayush.sawal@chelsio.com \
--cc=borisp@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=elver@google.com \
--cc=fenghua.yu@intel.com \
--cc=gnault@redhat.com \
--cc=guro@fb.com \
--cc=haokexin@gmail.com \
--cc=hawk@kernel.org \
--cc=hughd@google.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jakub@cloudflare.com \
--cc=jgg@ziepe.ca \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo@kernel.org \
--cc=mcroce@linux.microsoft.com \
--cc=mlindner@marvell.com \
--cc=mw@semihalf.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rohitm@chelsio.com \
--cc=saeedm@nvidia.com \
--cc=stephen@networkplumber.org \
--cc=sven.auhagen@voleatech.de \
--cc=tariqt@nvidia.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vbabka@suse.cz \
--cc=vinay.yadav@chelsio.com \
--cc=wenxu@ucloud.cn \
--cc=will@kernel.org \
--cc=willemb@google.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.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 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).