Currently page pool supports the below use cases:
use case 1: allocate page without page splitting using
page_pool_alloc_pages() API if the driver knows
that the memory it need is always bigger than
half of the page allocated from page pool.
use case 2: allocate page frag with page splitting using
page_pool_alloc_frag() API if the driver knows
that the memory it need is always smaller than
or equal to the half of the page allocated from
page pool.
There is emerging use case [1] & [2] that is a mix of the
above two case: the driver doesn't know the size of memory it
need beforehand, so the driver may use something like below to
allocate memory with least memory utilization and performance
penalty:
if (size << 1 > max_size)
page = page_pool_alloc_pages();
else
page = page_pool_alloc_frag();
To avoid the driver doing something like above, add the
page_pool_alloc() API to support the above use case, and update
the true size of memory that is acctually allocated by updating
'*size' back to the driver in order to avoid the truesize
underestimate problem.
1. https://lore.kernel.org/all/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1683896626.git.lorenzo@kernel.org/
2. https://lore.kernel.org/all/20230526054621.18371-3-liangchen.linux@gmail.com/
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
CC: Lorenzo Bianconi <lorenzo@kernel.org>
CC: Alexander Duyck <alexander.duyck@gmail.com>
---
include/net/page_pool.h | 43 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index 0b8cd2acc1d7..c135cd157cea 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -260,6 +260,49 @@ static inline struct page *page_pool_dev_alloc_frag(struct page_pool *pool,
return page_pool_alloc_frag(pool, offset, size, gfp);
}
+static inline struct page *page_pool_alloc(struct page_pool *pool,
+ unsigned int *offset,
+ unsigned int *size, gfp_t gfp)
+{
+ unsigned int max_size = PAGE_SIZE << pool->p.order;
+ struct page *page;
+
+ *size = ALIGN(*size, dma_get_cache_alignment());
+
+ if (WARN_ON(*size > max_size))
+ return NULL;
+
+ if ((*size << 1) > max_size || PAGE_POOL_DMA_USE_PP_FRAG_COUNT) {
+ *size = max_size;
+ *offset = 0;
+ return page_pool_alloc_pages(pool, gfp);
+ }
+
+ page = __page_pool_alloc_frag(pool, offset, *size, gfp);
+ if (unlikely(!page))
+ return NULL;
+
+ /* There is very likely not enough space for another frag, so append the
+ * remaining size to the current frag to avoid truesize underestimate
+ * problem.
+ */
+ if (pool->frag_offset + *size > max_size) {
+ *size = max_size - *offset;
+ pool->frag_offset = max_size;
+ }
+
+ return page;
+}
+
+static inline struct page *page_pool_dev_alloc(struct page_pool *pool,
+ unsigned int *offset,
+ unsigned int *size)
+{
+ gfp_t gfp = (GFP_ATOMIC | __GFP_NOWARN);
+
+ return page_pool_alloc(pool, offset, size, gfp);
+}
+
/* get the stored dma direction. A driver might decide to treat this locally and
* avoid the extra cache line from page_pool to determine the direction
*/
--
2.33.0From: Yunsheng Lin <linyunsheng@huawei.com> Date: Mon, 12 Jun 2023 21:02:54 +0800 > Currently page pool supports the below use cases: > use case 1: allocate page without page splitting using > page_pool_alloc_pages() API if the driver knows > that the memory it need is always bigger than > half of the page allocated from page pool. > use case 2: allocate page frag with page splitting using > page_pool_alloc_frag() API if the driver knows > that the memory it need is always smaller than > or equal to the half of the page allocated from > page pool. > > There is emerging use case [1] & [2] that is a mix of the > above two case: the driver doesn't know the size of memory it > need beforehand, so the driver may use something like below to > allocate memory with least memory utilization and performance > penalty: > > if (size << 1 > max_size) > page = page_pool_alloc_pages(); > else > page = page_pool_alloc_frag(); > > To avoid the driver doing something like above, add the > page_pool_alloc() API to support the above use case, and update > the true size of memory that is acctually allocated by updating > '*size' back to the driver in order to avoid the truesize > underestimate problem. > > 1. https://lore.kernel.org/all/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1683896626.git.lorenzo@kernel.org/ > 2. https://lore.kernel.org/all/20230526054621.18371-3-liangchen.linux@gmail.com/ > > Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> > CC: Lorenzo Bianconi <lorenzo@kernel.org> > CC: Alexander Duyck <alexander.duyck@gmail.com> > --- > include/net/page_pool.h | 43 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > > diff --git a/include/net/page_pool.h b/include/net/page_pool.h > index 0b8cd2acc1d7..c135cd157cea 100644 > --- a/include/net/page_pool.h > +++ b/include/net/page_pool.h > @@ -260,6 +260,49 @@ static inline struct page *page_pool_dev_alloc_frag(struct page_pool *pool, > return page_pool_alloc_frag(pool, offset, size, gfp); > } > > +static inline struct page *page_pool_alloc(struct page_pool *pool, > + unsigned int *offset, > + unsigned int *size, gfp_t gfp) Oh, really nice. Wouldn't you mind if I base my series on top of this? :) Also, with %PAGE_SIZE of 32k+ and default MTU, there is truesize underestimation. I haven't looked at the latest conversations as I had a small vacation, sowwy :s What's the current opinion on this? [...] Thanks, Olek
From: Alexander Lobakin <aleksander.lobakin@intel.com> Date: Tue, 13 Jun 2023 15:08:41 +0200 > From: Yunsheng Lin <linyunsheng@huawei.com> > Date: Mon, 12 Jun 2023 21:02:54 +0800 > >> Currently page pool supports the below use cases: >> use case 1: allocate page without page splitting using >> page_pool_alloc_pages() API if the driver knows >> that the memory it need is always bigger than >> half of the page allocated from page pool. >> use case 2: allocate page frag with page splitting using >> page_pool_alloc_frag() API if the driver knows >> that the memory it need is always smaller than >> or equal to the half of the page allocated from >> page pool. >> >> There is emerging use case [1] & [2] that is a mix of the >> above two case: the driver doesn't know the size of memory it >> need beforehand, so the driver may use something like below to >> allocate memory with least memory utilization and performance >> penalty: >> >> if (size << 1 > max_size) >> page = page_pool_alloc_pages(); >> else >> page = page_pool_alloc_frag(); >> >> To avoid the driver doing something like above, add the >> page_pool_alloc() API to support the above use case, and update >> the true size of memory that is acctually allocated by updating >> '*size' back to the driver in order to avoid the truesize >> underestimate problem. >> >> 1. https://lore.kernel.org/all/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1683896626.git.lorenzo@kernel.org/ >> 2. https://lore.kernel.org/all/20230526054621.18371-3-liangchen.linux@gmail.com/ >> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> >> CC: Lorenzo Bianconi <lorenzo@kernel.org> >> CC: Alexander Duyck <alexander.duyck@gmail.com> >> --- >> include/net/page_pool.h | 43 +++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 43 insertions(+) >> >> diff --git a/include/net/page_pool.h b/include/net/page_pool.h >> index 0b8cd2acc1d7..c135cd157cea 100644 >> --- a/include/net/page_pool.h >> +++ b/include/net/page_pool.h >> @@ -260,6 +260,49 @@ static inline struct page *page_pool_dev_alloc_frag(struct page_pool *pool, >> return page_pool_alloc_frag(pool, offset, size, gfp); >> } >> >> +static inline struct page *page_pool_alloc(struct page_pool *pool, >> + unsigned int *offset, >> + unsigned int *size, gfp_t gfp) > > Oh, really nice. Wouldn't you mind if I base my series on top of this? :) > > Also, with %PAGE_SIZE of 32k+ and default MTU, there is truesize > underestimation. I haven't looked at the latest conversations as I had a > small vacation, sowwy :s What's the current opinion on this? Please ignore this, seems like I didn't manage to read 2 lines below, you explicitly mention in the comment that you already handle this >_< Thanks, Olek
On 2023/6/13 21:11, Alexander Lobakin wrote: > From: Alexander Lobakin <aleksander.lobakin@intel.com> > Date: Tue, 13 Jun 2023 15:08:41 +0200 > >> From: Yunsheng Lin <linyunsheng@huawei.com> >> Date: Mon, 12 Jun 2023 21:02:54 +0800 >> >>> Currently page pool supports the below use cases: >>> use case 1: allocate page without page splitting using >>> page_pool_alloc_pages() API if the driver knows >>> that the memory it need is always bigger than >>> half of the page allocated from page pool. >>> use case 2: allocate page frag with page splitting using >>> page_pool_alloc_frag() API if the driver knows >>> that the memory it need is always smaller than >>> or equal to the half of the page allocated from >>> page pool. >>> >>> There is emerging use case [1] & [2] that is a mix of the >>> above two case: the driver doesn't know the size of memory it >>> need beforehand, so the driver may use something like below to >>> allocate memory with least memory utilization and performance >>> penalty: >>> >>> if (size << 1 > max_size) >>> page = page_pool_alloc_pages(); >>> else >>> page = page_pool_alloc_frag(); >>> >>> To avoid the driver doing something like above, add the >>> page_pool_alloc() API to support the above use case, and update >>> the true size of memory that is acctually allocated by updating >>> '*size' back to the driver in order to avoid the truesize >>> underestimate problem. >>> >>> 1. https://lore.kernel.org/all/d3ae6bd3537fbce379382ac6a42f67e22f27ece2.1683896626.git.lorenzo@kernel.org/ >>> 2. https://lore.kernel.org/all/20230526054621.18371-3-liangchen.linux@gmail.com/ >>> >>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> >>> CC: Lorenzo Bianconi <lorenzo@kernel.org> >>> CC: Alexander Duyck <alexander.duyck@gmail.com> >>> --- >>> include/net/page_pool.h | 43 +++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 43 insertions(+) >>> >>> diff --git a/include/net/page_pool.h b/include/net/page_pool.h >>> index 0b8cd2acc1d7..c135cd157cea 100644 >>> --- a/include/net/page_pool.h >>> +++ b/include/net/page_pool.h >>> @@ -260,6 +260,49 @@ static inline struct page *page_pool_dev_alloc_frag(struct page_pool *pool, >>> return page_pool_alloc_frag(pool, offset, size, gfp); >>> } >>> >>> +static inline struct page *page_pool_alloc(struct page_pool *pool, >>> + unsigned int *offset, >>> + unsigned int *size, gfp_t gfp) >> >> Oh, really nice. Wouldn't you mind if I base my series on top of this? :) No, I wouldn't mind. I am glad that if using the new API can both save memory and improve performance for your case:) >> >> Also, with %PAGE_SIZE of 32k+ and default MTU, there is truesize >> underestimation. I haven't looked at the latest conversations as I had a >> small vacation, sowwy :s What's the current opinion on this? > > Please ignore this, seems like I didn't manage to read 2 lines below, > you explicitly mention in the comment that you already handle this >_< > > Thanks, > Olek > > . >
© 2016 - 2024 Red Hat, Inc.