netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count
@ 2023-11-23  2:25 Liang Chen
  2023-11-23  2:25 ` [PATCH net-next v2 2/3] page_pool: halve BIAS_MAX for fragment multiple user references Liang Chen
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Liang Chen @ 2023-11-23  2:25 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, hawk, ilias.apalodimas, linyunsheng
  Cc: netdev, linux-mm, liangchen.linux

To support multiple users referencing the same fragment, pp_frag_count is
renamed to pp_ref_count to better reflect its actual meaning based on the
suggestion from [1].

[1]
http://lore.kernel.org/netdev/f71d9448-70c8-8793-dc9a-0eb48a570300@huawei.com

Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
---
 include/linux/mm_types.h        |  2 +-
 include/net/page_pool/helpers.h | 31 ++++++++++++++++++-------------
 2 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 957ce38768b2..64e4572ef06d 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -125,7 +125,7 @@ struct page {
 			struct page_pool *pp;
 			unsigned long _pp_mapping_pad;
 			unsigned long dma_addr;
-			atomic_long_t pp_frag_count;
+			atomic_long_t pp_ref_count;
 		};
 		struct {	/* Tail pages of compound page */
 			unsigned long compound_head;	/* Bit zero is set */
diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
index 4ebd544ae977..a6dc9412c9ae 100644
--- a/include/net/page_pool/helpers.h
+++ b/include/net/page_pool/helpers.h
@@ -29,7 +29,7 @@
  * page allocated from page pool. Page splitting enables memory saving and thus
  * avoids TLB/cache miss for data access, but there also is some cost to
  * implement page splitting, mainly some cache line dirtying/bouncing for
- * 'struct page' and atomic operation for page->pp_frag_count.
+ * 'struct page' and atomic operation for page->pp_ref_count.
  *
  * The API keeps track of in-flight pages, in order to let API users know when
  * it is safe to free a page_pool object, the API users must call
@@ -214,61 +214,66 @@ inline enum dma_data_direction page_pool_get_dma_dir(struct page_pool *pool)
 	return pool->p.dma_dir;
 }
 
-/* pp_frag_count represents the number of writers who can update the page
+/* pp_ref_count represents the number of writers who can update the page
  * either by updating skb->data or via DMA mappings for the device.
  * We can't rely on the page refcnt for that as we don't know who might be
  * holding page references and we can't reliably destroy or sync DMA mappings
  * of the fragments.
  *
- * When pp_frag_count reaches 0 we can either recycle the page if the page
+ * pp_ref_count initially corresponds to the number of fragments. However,
+ * when multiple users start to reference a single fragment, for example in
+ * skb_try_coalesce, the pp_ref_count will become greater than the number of
+ * fragments.
+ *
+ * When pp_ref_count reaches 0 we can either recycle the page if the page
  * refcnt is 1 or return it back to the memory allocator and destroy any
  * mappings we have.
  */
 static inline void page_pool_fragment_page(struct page *page, long nr)
 {
-	atomic_long_set(&page->pp_frag_count, nr);
+	atomic_long_set(&page->pp_ref_count, nr);
 }
 
 static inline long page_pool_defrag_page(struct page *page, long nr)
 {
 	long ret;
 
-	/* If nr == pp_frag_count then we have cleared all remaining
+	/* If nr == pp_ref_count then we have cleared all remaining
 	 * references to the page:
 	 * 1. 'n == 1': no need to actually overwrite it.
 	 * 2. 'n != 1': overwrite it with one, which is the rare case
-	 *              for pp_frag_count draining.
+	 *              for pp_ref_count draining.
 	 *
 	 * The main advantage to doing this is that not only we avoid a atomic
 	 * update, as an atomic_read is generally a much cheaper operation than
 	 * an atomic update, especially when dealing with a page that may be
-	 * partitioned into only 2 or 3 pieces; but also unify the pp_frag_count
+	 * partitioned into only 2 or 3 pieces; but also unify the pp_ref_count
 	 * handling by ensuring all pages have partitioned into only 1 piece
 	 * initially, and only overwrite it when the page is partitioned into
 	 * more than one piece.
 	 */
-	if (atomic_long_read(&page->pp_frag_count) == nr) {
+	if (atomic_long_read(&page->pp_ref_count) == nr) {
 		/* As we have ensured nr is always one for constant case using
 		 * the BUILD_BUG_ON(), only need to handle the non-constant case
-		 * here for pp_frag_count draining, which is a rare case.
+		 * here for pp_ref_count draining, which is a rare case.
 		 */
 		BUILD_BUG_ON(__builtin_constant_p(nr) && nr != 1);
 		if (!__builtin_constant_p(nr))
-			atomic_long_set(&page->pp_frag_count, 1);
+			atomic_long_set(&page->pp_ref_count, 1);
 
 		return 0;
 	}
 
-	ret = atomic_long_sub_return(nr, &page->pp_frag_count);
+	ret = atomic_long_sub_return(nr, &page->pp_ref_count);
 	WARN_ON(ret < 0);
 
-	/* We are the last user here too, reset pp_frag_count back to 1 to
+	/* We are the last user here too, reset pp_ref_count back to 1 to
 	 * ensure all pages have been partitioned into 1 piece initially,
 	 * this should be the rare case when the last two fragment users call
 	 * page_pool_defrag_page() currently.
 	 */
 	if (unlikely(!ret))
-		atomic_long_set(&page->pp_frag_count, 1);
+		atomic_long_set(&page->pp_ref_count, 1);
 
 	return ret;
 }
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH net-next v2 2/3] page_pool: halve BIAS_MAX for fragment multiple user references
  2023-11-23  2:25 [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Liang Chen
@ 2023-11-23  2:25 ` Liang Chen
  2023-11-23  2:25 ` [PATCH net-next v2 3/3] skbuff: Optimization of SKB coalescing for page pool Liang Chen
  2023-11-23  6:18 ` [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Yunsheng Lin
  2 siblings, 0 replies; 5+ messages in thread
From: Liang Chen @ 2023-11-23  2:25 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, hawk, ilias.apalodimas, linyunsheng
  Cc: netdev, linux-mm, liangchen.linux

Referring to patch [1], in order to support multiple users referencing the
same fragment and prevent overflow from pp_ref_count growing, the initial
value of pp_ref_count is halved, leaving room for pp_ref_count to increment
before the page is drained.

[1]
https://lore.kernel.org/all/20211009093724.10539-3-linyunsheng@huawei.com/

Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
---
 net/core/page_pool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index df2a06d7da52..5221b5b11bad 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -26,7 +26,7 @@
 #define DEFER_TIME (msecs_to_jiffies(1000))
 #define DEFER_WARN_INTERVAL (60 * HZ)
 
-#define BIAS_MAX	LONG_MAX
+#define BIAS_MAX	(LONG_MAX >> 1)
 
 #ifdef CONFIG_PAGE_POOL_STATS
 /* alloc_stat_inc is intended to be used in softirq context */
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH net-next v2 3/3] skbuff: Optimization of SKB coalescing for page pool
  2023-11-23  2:25 [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Liang Chen
  2023-11-23  2:25 ` [PATCH net-next v2 2/3] page_pool: halve BIAS_MAX for fragment multiple user references Liang Chen
@ 2023-11-23  2:25 ` Liang Chen
  2023-11-23  6:18 ` [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Yunsheng Lin
  2 siblings, 0 replies; 5+ messages in thread
From: Liang Chen @ 2023-11-23  2:25 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, hawk, ilias.apalodimas, linyunsheng
  Cc: netdev, linux-mm, liangchen.linux

In order to address the issues encountered with commit 1effe8ca4e34
("skbuff: fix coalescing for page_pool fragment recycling"), the
combination of the following condition was excluded from skb coalescing:

from->pp_recycle = 1
from->cloned = 1
to->pp_recycle = 1

However, with page pool environments, the aforementioned combination can
be quite common(ex. NetworkMananger may lead to the additional
packet_type being registered, thus the cloning). In scenarios with a
higher number of small packets, it can significantly affect the success
rate of coalescing. For example, considering packets of 256 bytes size,
our comparison of coalescing success rate is as follows:

Without page pool: 70%
With page pool: 13%

Consequently, this has an impact on performance:

Without page pool: 2.57 Gbits/sec
With page pool: 2.26 Gbits/sec

Therefore, it seems worthwhile to optimize this scenario and enable
coalescing of this particular combination. To achieve this, we need to
ensure the correct increment of the "from" SKB page's page pool
reference count (pp_ref_count).

Following this optimization, the success rate of coalescing measured in
our environment has improved as follows:

With page pool: 60%

This success rate is approaching the rate achieved without using page
pool, and the performance has also been improved:

With page pool: 2.52 Gbits/sec

Below is the performance comparison for small packets before and after
this optimization. We observe no impact to packets larger than 4K.

packet size     before      after       improved
(bytes)         (Gbits/sec) (Gbits/sec)
128             1.19        1.27        7.13%
256             2.26        2.52        11.75%
512             4.13        4.81        16.50%
1024            6.17        6.73        9.05%
2048            14.54       15.47       6.45%
4096            25.44       27.87       9.52%

Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
---
Changes from v1:
- make use of the unified pp fragment and non-fragment api
---
 include/net/page_pool/helpers.h | 22 ++++++++++++++++++++++
 net/core/skbuff.c               | 23 +++++++++++------------
 2 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
index a6dc9412c9ae..8d2e3495f17d 100644
--- a/include/net/page_pool/helpers.h
+++ b/include/net/page_pool/helpers.h
@@ -402,4 +402,26 @@ static inline void page_pool_nid_changed(struct page_pool *pool, int new_nid)
 		page_pool_update_nid(pool, new_nid);
 }
 
+static inline bool page_pool_is_pp_page(struct page *page)
+{
+	return (page->pp_magic & ~0x3UL) == PP_SIGNATURE;
+}
+
+/**
+ * page_pool_get_frag_ref() - Increase fragment reference count of a page
+ * @page:	page of the fragment on which to increase a reference
+ *
+ * Increase fragment reference count (pp_ref_count) on a page, but if it is
+ * not a page pool page, fallback to increase a reference(_refcount) on a
+ * normal page.
+ */
+static inline void page_pool_get_frag_ref(struct page *page)
+{
+	struct page *head_page = compound_head(page);
+
+	if (likely(page_pool_is_pp_page(head_page)))
+		atomic_long_inc(&head_page->pp_ref_count);
+	else
+		get_page(head_page);
+}
 #endif /* _NET_PAGE_POOL_HELPERS_H */
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index b157efea5dea..54e6945ead56 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5764,17 +5764,12 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
 		return false;
 
 	/* In general, avoid mixing page_pool and non-page_pool allocated
-	 * pages within the same SKB. Additionally avoid dealing with clones
-	 * with page_pool pages, in case the SKB is using page_pool fragment
-	 * references (page_pool_alloc_frag()). Since we only take full page
-	 * references for cloned SKBs at the moment that would result in
-	 * inconsistent reference counts.
-	 * In theory we could take full references if @from is cloned and
-	 * !@to->pp_recycle but its tricky (due to potential race with
-	 * the clone disappearing) and rare, so not worth dealing with.
+	 * pages within the same SKB. In theory we could take full
+	 * references if @from is cloned and !@to->pp_recycle but its
+	 * tricky (due to potential race with the clone disappearing) and
+	 * rare, so not worth dealing with.
 	 */
-	if (to->pp_recycle != from->pp_recycle ||
-	    (from->pp_recycle && skb_cloned(from)))
+	if (to->pp_recycle != from->pp_recycle)
 		return false;
 
 	if (len <= skb_tailroom(to)) {
@@ -5831,8 +5826,12 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
 	/* if the skb is not cloned this does nothing
 	 * since we set nr_frags to 0.
 	 */
-	for (i = 0; i < from_shinfo->nr_frags; i++)
-		__skb_frag_ref(&from_shinfo->frags[i]);
+	if (from->pp_recycle)
+		for (i = 0; i < from_shinfo->nr_frags; i++)
+			page_pool_get_frag_ref(skb_frag_page(&from_shinfo->frags[i]));
+	else
+		for (i = 0; i < from_shinfo->nr_frags; i++)
+			__skb_frag_ref(&from_shinfo->frags[i]);
 
 	to->truesize += delta;
 	to->len += len;
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count
  2023-11-23  2:25 [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Liang Chen
  2023-11-23  2:25 ` [PATCH net-next v2 2/3] page_pool: halve BIAS_MAX for fragment multiple user references Liang Chen
  2023-11-23  2:25 ` [PATCH net-next v2 3/3] skbuff: Optimization of SKB coalescing for page pool Liang Chen
@ 2023-11-23  6:18 ` Yunsheng Lin
  2023-11-23 14:30   ` Liang Chen
  2 siblings, 1 reply; 5+ messages in thread
From: Yunsheng Lin @ 2023-11-23  6:18 UTC (permalink / raw)
  To: Liang Chen, davem, edumazet, kuba, pabeni, hawk, ilias.apalodimas
  Cc: netdev, linux-mm

On 2023/11/23 10:25, Liang Chen wrote:
> To support multiple users referencing the same fragment, pp_frag_count is
> renamed to pp_ref_count to better reflect its actual meaning based on the
> suggestion from [1].

The renaming looks good to me, some minor nit.

It is good to add a cover-letter using 'git format-patch --cover-letter'
to explain the overall background or modifications this patchset make when
there is more than one patch.

> 
> [1]
> http://lore.kernel.org/netdev/f71d9448-70c8-8793-dc9a-0eb48a570300@huawei.com
> 
> Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
> ---
>  include/linux/mm_types.h        |  2 +-
>  include/net/page_pool/helpers.h | 31 ++++++++++++++++++-------------
>  2 files changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 957ce38768b2..64e4572ef06d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -125,7 +125,7 @@ struct page {
>  			struct page_pool *pp;
>  			unsigned long _pp_mapping_pad;
>  			unsigned long dma_addr;
> -			atomic_long_t pp_frag_count;
> +			atomic_long_t pp_ref_count;

It seems that we may have 4 bytes available for 64 bit arch if we change
the 'atomic_long_t' to 'refcount_t':)

>  		};
>  		struct {	/* Tail pages of compound page */
>  			unsigned long compound_head;	/* Bit zero is set */
> diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> index 4ebd544ae977..a6dc9412c9ae 100644
> --- a/include/net/page_pool/helpers.h
> +++ b/include/net/page_pool/helpers.h
> @@ -29,7 +29,7 @@
>   * page allocated from page pool. Page splitting enables memory saving and thus
>   * avoids TLB/cache miss for data access, but there also is some cost to
>   * implement page splitting, mainly some cache line dirtying/bouncing for
> - * 'struct page' and atomic operation for page->pp_frag_count.
> + * 'struct page' and atomic operation for page->pp_ref_count.
>   *
>   * The API keeps track of in-flight pages, in order to let API users know when
>   * it is safe to free a page_pool object, the API users must call
> @@ -214,61 +214,66 @@ inline enum dma_data_direction page_pool_get_dma_dir(struct page_pool *pool)
>  	return pool->p.dma_dir;
>  }
>  
> -/* pp_frag_count represents the number of writers who can update the page
> +/* pp_ref_count represents the number of writers who can update the page
>   * either by updating skb->data or via DMA mappings for the device.
>   * We can't rely on the page refcnt for that as we don't know who might be
>   * holding page references and we can't reliably destroy or sync DMA mappings
>   * of the fragments.
>   *
> - * When pp_frag_count reaches 0 we can either recycle the page if the page
> + * pp_ref_count initially corresponds to the number of fragments. However,
> + * when multiple users start to reference a single fragment, for example in
> + * skb_try_coalesce, the pp_ref_count will become greater than the number of
> + * fragments.
> + *
> + * When pp_ref_count reaches 0 we can either recycle the page if the page
>   * refcnt is 1 or return it back to the memory allocator and destroy any
>   * mappings we have.
>   */
>  static inline void page_pool_fragment_page(struct page *page, long nr)
>  {
> -	atomic_long_set(&page->pp_frag_count, nr);
> +	atomic_long_set(&page->pp_ref_count, nr);
>  }
>  
>  static inline long page_pool_defrag_page(struct page *page, long nr)
>  {
>  	long ret;
>  
> -	/* If nr == pp_frag_count then we have cleared all remaining
> +	/* If nr == pp_ref_count then we have cleared all remaining
>  	 * references to the page:
>  	 * 1. 'n == 1': no need to actually overwrite it.
>  	 * 2. 'n != 1': overwrite it with one, which is the rare case
> -	 *              for pp_frag_count draining.
> +	 *              for pp_ref_count draining.
>  	 *
>  	 * The main advantage to doing this is that not only we avoid a atomic
>  	 * update, as an atomic_read is generally a much cheaper operation than
>  	 * an atomic update, especially when dealing with a page that may be
> -	 * partitioned into only 2 or 3 pieces; but also unify the pp_frag_count
> +	 * partitioned into only 2 or 3 pieces; but also unify the pp_ref_count

Maybe "referenced by only 2 or 3 users" is more appropriate now?

>  	 * handling by ensuring all pages have partitioned into only 1 piece
>  	 * initially, and only overwrite it when the page is partitioned into
>  	 * more than one piece.
>  	 */
> -	if (atomic_long_read(&page->pp_frag_count) == nr) {
> +	if (atomic_long_read(&page->pp_ref_count) == nr) {
>  		/* As we have ensured nr is always one for constant case using
>  		 * the BUILD_BUG_ON(), only need to handle the non-constant case
> -		 * here for pp_frag_count draining, which is a rare case.
> +		 * here for pp_ref_count draining, which is a rare case.
>  		 */
>  		BUILD_BUG_ON(__builtin_constant_p(nr) && nr != 1);
>  		if (!__builtin_constant_p(nr))
> -			atomic_long_set(&page->pp_frag_count, 1);
> +			atomic_long_set(&page->pp_ref_count, 1);
>  
>  		return 0;
>  	}
>  
> -	ret = atomic_long_sub_return(nr, &page->pp_frag_count);
> +	ret = atomic_long_sub_return(nr, &page->pp_ref_count);
>  	WARN_ON(ret < 0);
>  
> -	/* We are the last user here too, reset pp_frag_count back to 1 to
> +	/* We are the last user here too, reset pp_ref_count back to 1 to
>  	 * ensure all pages have been partitioned into 1 piece initially,
>  	 * this should be the rare case when the last two fragment users call
>  	 * page_pool_defrag_page() currently.

Do we need to rename the page_pool_defrag_page() and page_pool_is_last_frag()
too?

>  	 */
>  	if (unlikely(!ret))
> -		atomic_long_set(&page->pp_frag_count, 1);
> +		atomic_long_set(&page->pp_ref_count, 1);
>  
>  	return ret;
>  }
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count
  2023-11-23  6:18 ` [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Yunsheng Lin
@ 2023-11-23 14:30   ` Liang Chen
  0 siblings, 0 replies; 5+ messages in thread
From: Liang Chen @ 2023-11-23 14:30 UTC (permalink / raw)
  To: Yunsheng Lin
  Cc: davem, edumazet, kuba, pabeni, hawk, ilias.apalodimas, netdev, linux-mm

On Thu, Nov 23, 2023 at 2:18 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2023/11/23 10:25, Liang Chen wrote:
> > To support multiple users referencing the same fragment, pp_frag_count is
> > renamed to pp_ref_count to better reflect its actual meaning based on the
> > suggestion from [1].
>
> The renaming looks good to me, some minor nit.
>
> It is good to add a cover-letter using 'git format-patch --cover-letter'
> to explain the overall background or modifications this patchset make when
> there is more than one patch.
>

Thanks for the suggestion. A cover-letter will be provided for the next version.
> >
> > [1]
> > http://lore.kernel.org/netdev/f71d9448-70c8-8793-dc9a-0eb48a570300@huawei.com
> >
> > Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
> > ---
> >  include/linux/mm_types.h        |  2 +-
> >  include/net/page_pool/helpers.h | 31 ++++++++++++++++++-------------
> >  2 files changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 957ce38768b2..64e4572ef06d 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -125,7 +125,7 @@ struct page {
> >                       struct page_pool *pp;
> >                       unsigned long _pp_mapping_pad;
> >                       unsigned long dma_addr;
> > -                     atomic_long_t pp_frag_count;
> > +                     atomic_long_t pp_ref_count;
>
> It seems that we may have 4 bytes available for 64 bit arch if we change
> the 'atomic_long_t' to 'refcount_t':)
>
> >               };
> >               struct {        /* Tail pages of compound page */
> >                       unsigned long compound_head;    /* Bit zero is set */
> > diff --git a/include/net/page_pool/helpers.h b/include/net/page_pool/helpers.h
> > index 4ebd544ae977..a6dc9412c9ae 100644
> > --- a/include/net/page_pool/helpers.h
> > +++ b/include/net/page_pool/helpers.h
> > @@ -29,7 +29,7 @@
> >   * page allocated from page pool. Page splitting enables memory saving and thus
> >   * avoids TLB/cache miss for data access, but there also is some cost to
> >   * implement page splitting, mainly some cache line dirtying/bouncing for
> > - * 'struct page' and atomic operation for page->pp_frag_count.
> > + * 'struct page' and atomic operation for page->pp_ref_count.
> >   *
> >   * The API keeps track of in-flight pages, in order to let API users know when
> >   * it is safe to free a page_pool object, the API users must call
> > @@ -214,61 +214,66 @@ inline enum dma_data_direction page_pool_get_dma_dir(struct page_pool *pool)
> >       return pool->p.dma_dir;
> >  }
> >
> > -/* pp_frag_count represents the number of writers who can update the page
> > +/* pp_ref_count represents the number of writers who can update the page
> >   * either by updating skb->data or via DMA mappings for the device.
> >   * We can't rely on the page refcnt for that as we don't know who might be
> >   * holding page references and we can't reliably destroy or sync DMA mappings
> >   * of the fragments.
> >   *
> > - * When pp_frag_count reaches 0 we can either recycle the page if the page
> > + * pp_ref_count initially corresponds to the number of fragments. However,
> > + * when multiple users start to reference a single fragment, for example in
> > + * skb_try_coalesce, the pp_ref_count will become greater than the number of
> > + * fragments.
> > + *
> > + * When pp_ref_count reaches 0 we can either recycle the page if the page
> >   * refcnt is 1 or return it back to the memory allocator and destroy any
> >   * mappings we have.
> >   */
> >  static inline void page_pool_fragment_page(struct page *page, long nr)
> >  {
> > -     atomic_long_set(&page->pp_frag_count, nr);
> > +     atomic_long_set(&page->pp_ref_count, nr);
> >  }
> >
> >  static inline long page_pool_defrag_page(struct page *page, long nr)
> >  {
> >       long ret;
> >
> > -     /* If nr == pp_frag_count then we have cleared all remaining
> > +     /* If nr == pp_ref_count then we have cleared all remaining
> >        * references to the page:
> >        * 1. 'n == 1': no need to actually overwrite it.
> >        * 2. 'n != 1': overwrite it with one, which is the rare case
> > -      *              for pp_frag_count draining.
> > +      *              for pp_ref_count draining.
> >        *
> >        * The main advantage to doing this is that not only we avoid a atomic
> >        * update, as an atomic_read is generally a much cheaper operation than
> >        * an atomic update, especially when dealing with a page that may be
> > -      * partitioned into only 2 or 3 pieces; but also unify the pp_frag_count
> > +      * partitioned into only 2 or 3 pieces; but also unify the pp_ref_count
>
> Maybe "referenced by only 2 or 3 users" is more appropriate now?
>

Sure.
> >        * handling by ensuring all pages have partitioned into only 1 piece
> >        * initially, and only overwrite it when the page is partitioned into
> >        * more than one piece.
> >        */
> > -     if (atomic_long_read(&page->pp_frag_count) == nr) {
> > +     if (atomic_long_read(&page->pp_ref_count) == nr) {
> >               /* As we have ensured nr is always one for constant case using
> >                * the BUILD_BUG_ON(), only need to handle the non-constant case
> > -              * here for pp_frag_count draining, which is a rare case.
> > +              * here for pp_ref_count draining, which is a rare case.
> >                */
> >               BUILD_BUG_ON(__builtin_constant_p(nr) && nr != 1);
> >               if (!__builtin_constant_p(nr))
> > -                     atomic_long_set(&page->pp_frag_count, 1);
> > +                     atomic_long_set(&page->pp_ref_count, 1);
> >
> >               return 0;
> >       }
> >
> > -     ret = atomic_long_sub_return(nr, &page->pp_frag_count);
> > +     ret = atomic_long_sub_return(nr, &page->pp_ref_count);
> >       WARN_ON(ret < 0);
> >
> > -     /* We are the last user here too, reset pp_frag_count back to 1 to
> > +     /* We are the last user here too, reset pp_ref_count back to 1 to
> >        * ensure all pages have been partitioned into 1 piece initially,
> >        * this should be the rare case when the last two fragment users call
> >        * page_pool_defrag_page() currently.
>
> Do we need to rename the page_pool_defrag_page() and page_pool_is_last_frag()
> too?
>

Yeah, I think so. Once a pp page is drained, its management shifts to
being primarily governed by pp_ref_count, and there's no longer a need
to consider fragmenting. will be done in the next iteration.
> >        */
> >       if (unlikely(!ret))
> > -             atomic_long_set(&page->pp_frag_count, 1);
> > +             atomic_long_set(&page->pp_ref_count, 1);
> >
> >       return ret;
> >  }
> >

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-11-23 14:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-23  2:25 [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Liang Chen
2023-11-23  2:25 ` [PATCH net-next v2 2/3] page_pool: halve BIAS_MAX for fragment multiple user references Liang Chen
2023-11-23  2:25 ` [PATCH net-next v2 3/3] skbuff: Optimization of SKB coalescing for page pool Liang Chen
2023-11-23  6:18 ` [PATCH net-next v2 1/3] page_pool: Rename pp_frag_count to pp_ref_count Yunsheng Lin
2023-11-23 14:30   ` Liang Chen

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).