* [PATCH net-next v2 0/2] Some minor optimization for page pool
@ 2021-08-20 6:56 Yunsheng Lin
2021-08-20 6:56 ` [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting Yunsheng Lin
2021-08-20 6:56 ` [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping Yunsheng Lin
0 siblings, 2 replies; 9+ messages in thread
From: Yunsheng Lin @ 2021-08-20 6:56 UTC (permalink / raw)
To: davem, kuba; +Cc: hawk, ilias.apalodimas, netdev, linux-kernel, hkallweit1
Patch 1: Use relaxed atomic for release side accounting
Patch 2: Minor optimize for page_pool_dma_map() function
V2: Remove unnecessary unliky() mark as pointed out by
Heiner.
Yunsheng Lin (2):
page_pool: use relaxed atomic for release side accounting
page_pool: optimize the cpu sync operation when DMA mapping
net/core/page_pool.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting 2021-08-20 6:56 [PATCH net-next v2 0/2] Some minor optimization for page pool Yunsheng Lin @ 2021-08-20 6:56 ` Yunsheng Lin 2021-08-20 7:12 ` Jesper Dangaard Brouer 2021-08-20 6:56 ` [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping Yunsheng Lin 1 sibling, 1 reply; 9+ messages in thread From: Yunsheng Lin @ 2021-08-20 6:56 UTC (permalink / raw) To: davem, kuba; +Cc: hawk, ilias.apalodimas, netdev, linux-kernel, hkallweit1 There is no need to synchronize the account updating, so use the relaxed atomic to avoid some memory barrier in the data path. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.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 e140905..1a69784 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -370,7 +370,7 @@ void page_pool_release_page(struct page_pool *pool, struct page *page) /* This may be the last page returned, releasing the pool, so * it is not safe to reference pool afterwards. */ - count = atomic_inc_return(&pool->pages_state_release_cnt); + count = atomic_inc_return_relaxed(&pool->pages_state_release_cnt); trace_page_pool_state_release(pool, page, count); } EXPORT_SYMBOL(page_pool_release_page); -- 2.7.4 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting 2021-08-20 6:56 ` [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting Yunsheng Lin @ 2021-08-20 7:12 ` Jesper Dangaard Brouer 0 siblings, 0 replies; 9+ messages in thread From: Jesper Dangaard Brouer @ 2021-08-20 7:12 UTC (permalink / raw) To: Yunsheng Lin, davem, kuba Cc: brouer, hawk, ilias.apalodimas, netdev, linux-kernel, hkallweit1 On 20/08/2021 08.56, Yunsheng Lin wrote: > There is no need to synchronize the account updating, so > use the relaxed atomic to avoid some memory barrier in the > data path. > > Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> LGTM Acked-by: Jesper Dangaard Brouer <brouer@redhat.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 e140905..1a69784 100644 > --- a/net/core/page_pool.c > +++ b/net/core/page_pool.c > @@ -370,7 +370,7 @@ void page_pool_release_page(struct page_pool *pool, struct page *page) > /* This may be the last page returned, releasing the pool, so > * it is not safe to reference pool afterwards. > */ > - count = atomic_inc_return(&pool->pages_state_release_cnt); > + count = atomic_inc_return_relaxed(&pool->pages_state_release_cnt); > trace_page_pool_state_release(pool, page, count); > } > EXPORT_SYMBOL(page_pool_release_page); > ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-20 6:56 [PATCH net-next v2 0/2] Some minor optimization for page pool Yunsheng Lin 2021-08-20 6:56 ` [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting Yunsheng Lin @ 2021-08-20 6:56 ` Yunsheng Lin 2021-08-20 9:39 ` Ilias Apalodimas 1 sibling, 1 reply; 9+ messages in thread From: Yunsheng Lin @ 2021-08-20 6:56 UTC (permalink / raw) To: davem, kuba; +Cc: hawk, ilias.apalodimas, netdev, linux-kernel, hkallweit1 If the DMA_ATTR_SKIP_CPU_SYNC is not set, cpu syncing is also done in dma_map_page_attrs(), so set the attrs according to pool->p.flags to avoid calling cpu sync function again. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> --- net/core/page_pool.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/net/core/page_pool.c b/net/core/page_pool.c index 1a69784..3df5554 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -191,8 +191,12 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool, static bool page_pool_dma_map(struct page_pool *pool, struct page *page) { + unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC; dma_addr_t dma; + if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) + attrs = 0; + /* Setup DMA mapping: use 'struct page' area for storing DMA-addr * since dma_addr_t can be either 32 or 64 bits and does not always fit * into page private data (i.e 32bit cpu with 64bit DMA caps) @@ -200,15 +204,12 @@ static bool page_pool_dma_map(struct page_pool *pool, struct page *page) */ dma = dma_map_page_attrs(pool->p.dev, page, 0, (PAGE_SIZE << pool->p.order), - pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC); + pool->p.dma_dir, attrs); if (dma_mapping_error(pool->p.dev, dma)) return false; page_pool_set_dma_addr(page, dma); - if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) - page_pool_dma_sync_for_device(pool, page, pool->p.max_len); - return true; } -- 2.7.4 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-20 6:56 ` [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping Yunsheng Lin @ 2021-08-20 9:39 ` Ilias Apalodimas 2021-08-23 3:56 ` Yunsheng Lin 0 siblings, 1 reply; 9+ messages in thread From: Ilias Apalodimas @ 2021-08-20 9:39 UTC (permalink / raw) To: Yunsheng Lin; +Cc: davem, kuba, hawk, netdev, linux-kernel, hkallweit1 On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote: > If the DMA_ATTR_SKIP_CPU_SYNC is not set, cpu syncing is > also done in dma_map_page_attrs(), so set the attrs according > to pool->p.flags to avoid calling cpu sync function again. Isn't DMA_ATTR_SKIP_CPU_SYNC checked within dma_map_page_attrs() anyway? Regards /Ilias > > Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> > --- > net/core/page_pool.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/net/core/page_pool.c b/net/core/page_pool.c > index 1a69784..3df5554 100644 > --- a/net/core/page_pool.c > +++ b/net/core/page_pool.c > @@ -191,8 +191,12 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool, > > static bool page_pool_dma_map(struct page_pool *pool, struct page *page) > { > + unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC; > dma_addr_t dma; > > + if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > + attrs = 0; > + > /* Setup DMA mapping: use 'struct page' area for storing DMA-addr > * since dma_addr_t can be either 32 or 64 bits and does not always fit > * into page private data (i.e 32bit cpu with 64bit DMA caps) > @@ -200,15 +204,12 @@ static bool page_pool_dma_map(struct page_pool *pool, struct page *page) > */ > dma = dma_map_page_attrs(pool->p.dev, page, 0, > (PAGE_SIZE << pool->p.order), > - pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > + pool->p.dma_dir, attrs); > if (dma_mapping_error(pool->p.dev, dma)) > return false; > > page_pool_set_dma_addr(page, dma); > > - if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > - page_pool_dma_sync_for_device(pool, page, pool->p.max_len); > - > return true; > } > > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-20 9:39 ` Ilias Apalodimas @ 2021-08-23 3:56 ` Yunsheng Lin 2021-08-23 12:42 ` Ilias Apalodimas 0 siblings, 1 reply; 9+ messages in thread From: Yunsheng Lin @ 2021-08-23 3:56 UTC (permalink / raw) To: Ilias Apalodimas; +Cc: davem, kuba, hawk, netdev, linux-kernel, hkallweit1 On 2021/8/20 17:39, Ilias Apalodimas wrote: > On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote: >> If the DMA_ATTR_SKIP_CPU_SYNC is not set, cpu syncing is >> also done in dma_map_page_attrs(), so set the attrs according >> to pool->p.flags to avoid calling cpu sync function again. > > Isn't DMA_ATTR_SKIP_CPU_SYNC checked within dma_map_page_attrs() anyway? Yes, the checking in dma_map_page_attrs() should save us from calling dma_sync_single_for_device() again if we set the attrs according to "pool->p.flags & PP_FLAG_DMA_SYNC_DEV". As dma_sync_single_for_device() is EXPORT_SYMBOL()'ed, and should be a no-op for dma coherent device, so there may be a function calling overhead for dma coherent device, letting dma_map_page_attrs() handling the sync seems to avoid the stack pushing/poping overhead: https://elixir.bootlin.com/linux/latest/source/kernel/dma/direct.h#L104 The one thing I am not sure about is that the pool->p.offset and pool->p.max_len are used to decide the sync range before this patch, while the sync range is the same as the map range when doing the sync in dma_map_page_attrs(). I assumed the above is not a issue? only sync more than we need? and it won't hurt the performance? > > Regards > /Ilias >> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> >> --- >> net/core/page_pool.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/net/core/page_pool.c b/net/core/page_pool.c >> index 1a69784..3df5554 100644 >> --- a/net/core/page_pool.c >> +++ b/net/core/page_pool.c >> @@ -191,8 +191,12 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool, >> >> static bool page_pool_dma_map(struct page_pool *pool, struct page *page) >> { >> + unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC; >> dma_addr_t dma; >> >> + if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) >> + attrs = 0; >> + >> /* Setup DMA mapping: use 'struct page' area for storing DMA-addr >> * since dma_addr_t can be either 32 or 64 bits and does not always fit >> * into page private data (i.e 32bit cpu with 64bit DMA caps) >> @@ -200,15 +204,12 @@ static bool page_pool_dma_map(struct page_pool *pool, struct page *page) >> */ >> dma = dma_map_page_attrs(pool->p.dev, page, 0, >> (PAGE_SIZE << pool->p.order), >> - pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC); >> + pool->p.dma_dir, attrs); >> if (dma_mapping_error(pool->p.dev, dma)) >> return false; >> >> page_pool_set_dma_addr(page, dma); >> >> - if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) >> - page_pool_dma_sync_for_device(pool, page, pool->p.max_len); >> - >> return true; >> } >> >> -- >> 2.7.4 >> > . > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-23 3:56 ` Yunsheng Lin @ 2021-08-23 12:42 ` Ilias Apalodimas 2021-08-24 7:00 ` Yunsheng Lin 0 siblings, 1 reply; 9+ messages in thread From: Ilias Apalodimas @ 2021-08-23 12:42 UTC (permalink / raw) To: Yunsheng Lin; +Cc: davem, kuba, hawk, netdev, linux-kernel, hkallweit1 On Mon, Aug 23, 2021 at 11:56:48AM +0800, Yunsheng Lin wrote: > On 2021/8/20 17:39, Ilias Apalodimas wrote: > > On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote: > >> If the DMA_ATTR_SKIP_CPU_SYNC is not set, cpu syncing is > >> also done in dma_map_page_attrs(), so set the attrs according > >> to pool->p.flags to avoid calling cpu sync function again. > > > > Isn't DMA_ATTR_SKIP_CPU_SYNC checked within dma_map_page_attrs() anyway? > > Yes, the checking in dma_map_page_attrs() should save us from > calling dma_sync_single_for_device() again if we set the attrs > according to "pool->p.flags & PP_FLAG_DMA_SYNC_DEV". But we aren't syncing anything right now when we allocate the pages since this is called with DMA_ATTR_SKIP_CPU_SYNC. We are syncing the allocated range on the end of the function, if the pool was created and was requested to take care of the mappings for us. > > As dma_sync_single_for_device() is EXPORT_SYMBOL()'ed, and > should be a no-op for dma coherent device, so there may be a > function calling overhead for dma coherent device, letting > dma_map_page_attrs() handling the sync seems to avoid the stack > pushing/poping overhead: > > https://elixir.bootlin.com/linux/latest/source/kernel/dma/direct.h#L104 > > The one thing I am not sure about is that the pool->p.offset > and pool->p.max_len are used to decide the sync range before this > patch, while the sync range is the same as the map range when doing > the sync in dma_map_page_attrs(). I am not sure I am following here. We always sync the entire range as well in the current code as the mapping function is called with max_len. > > I assumed the above is not a issue? only sync more than we need? > and it won't hurt the performance? We can sync more than we need, but if it's a non-coherent architecture, there's a performance penalty. Regards /Ilias > > > > > Regards > > /Ilias > >> > >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> > >> --- > >> net/core/page_pool.c | 9 +++++---- > >> 1 file changed, 5 insertions(+), 4 deletions(-) > >> > >> diff --git a/net/core/page_pool.c b/net/core/page_pool.c > >> index 1a69784..3df5554 100644 > >> --- a/net/core/page_pool.c > >> +++ b/net/core/page_pool.c > >> @@ -191,8 +191,12 @@ static void page_pool_dma_sync_for_device(struct page_pool *pool, > >> > >> static bool page_pool_dma_map(struct page_pool *pool, struct page *page) > >> { > >> + unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC; > >> dma_addr_t dma; > >> > >> + if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > >> + attrs = 0; > >> + > >> /* Setup DMA mapping: use 'struct page' area for storing DMA-addr > >> * since dma_addr_t can be either 32 or 64 bits and does not always fit > >> * into page private data (i.e 32bit cpu with 64bit DMA caps) > >> @@ -200,15 +204,12 @@ static bool page_pool_dma_map(struct page_pool *pool, struct page *page) > >> */ > >> dma = dma_map_page_attrs(pool->p.dev, page, 0, > >> (PAGE_SIZE << pool->p.order), > >> - pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC); > >> + pool->p.dma_dir, attrs); > >> if (dma_mapping_error(pool->p.dev, dma)) > >> return false; > >> > >> page_pool_set_dma_addr(page, dma); > >> > >> - if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > >> - page_pool_dma_sync_for_device(pool, page, pool->p.max_len); > >> - > >> return true; > >> } > >> > >> -- > >> 2.7.4 > >> > > . > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-23 12:42 ` Ilias Apalodimas @ 2021-08-24 7:00 ` Yunsheng Lin 2021-08-24 9:04 ` Ilias Apalodimas 0 siblings, 1 reply; 9+ messages in thread From: Yunsheng Lin @ 2021-08-24 7:00 UTC (permalink / raw) To: Ilias Apalodimas; +Cc: davem, kuba, hawk, netdev, linux-kernel, hkallweit1 On 2021/8/23 20:42, Ilias Apalodimas wrote: > On Mon, Aug 23, 2021 at 11:56:48AM +0800, Yunsheng Lin wrote: >> On 2021/8/20 17:39, Ilias Apalodimas wrote: >>> On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote: [..] >> >> https://elixir.bootlin.com/linux/latest/source/kernel/dma/direct.h#L104 >> >> The one thing I am not sure about is that the pool->p.offset >> and pool->p.max_len are used to decide the sync range before this >> patch, while the sync range is the same as the map range when doing >> the sync in dma_map_page_attrs(). > > I am not sure I am following here. We always sync the entire range as well > in the current code as the mapping function is called with max_len. > >> >> I assumed the above is not a issue? only sync more than we need? >> and it won't hurt the performance? > > We can sync more than we need, but if it's a non-coherent architecture, > there's a performance penalty. Since I do not have any performance data to prove if there is a performance penalty for non-coherent architecture, I will drop it:) > > Regards > /Ilias >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping 2021-08-24 7:00 ` Yunsheng Lin @ 2021-08-24 9:04 ` Ilias Apalodimas 0 siblings, 0 replies; 9+ messages in thread From: Ilias Apalodimas @ 2021-08-24 9:04 UTC (permalink / raw) To: Yunsheng Lin, Lorenzo Bianconi Cc: David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer, Networking, open list, Heiner Kallweit Hi Yunsheng, +cc Lorenzo, which has done some tests on non-coherent platforms On Tue, 24 Aug 2021 at 10:00, Yunsheng Lin <linyunsheng@huawei.com> wrote: > > On 2021/8/23 20:42, Ilias Apalodimas wrote: > > On Mon, Aug 23, 2021 at 11:56:48AM +0800, Yunsheng Lin wrote: > >> On 2021/8/20 17:39, Ilias Apalodimas wrote: > >>> On Fri, Aug 20, 2021 at 02:56:51PM +0800, Yunsheng Lin wrote: > > [..] > >> > >> https://elixir.bootlin.com/linux/latest/source/kernel/dma/direct.h#L104 > >> > >> The one thing I am not sure about is that the pool->p.offset > >> and pool->p.max_len are used to decide the sync range before this > >> patch, while the sync range is the same as the map range when doing > >> the sync in dma_map_page_attrs(). > > > > I am not sure I am following here. We always sync the entire range as well > > in the current code as the mapping function is called with max_len. > > > >> > >> I assumed the above is not a issue? only sync more than we need? > >> and it won't hurt the performance? > > > > We can sync more than we need, but if it's a non-coherent architecture, > > there's a performance penalty. > > Since I do not have any performance data to prove if there is a > performance penalty for non-coherent architecture, I will drop it:) I am pretty sure it does affect it. Unless I am missing something the patch simply re-arranges calls to avoid calling dma_map_page_attrs() right? However since dma_map_page_attrs() won't do anything sync-related since it's called with DMA_ATTR_SKIP_CPU_SYNC, I doubt calling it will have any measurable difference. If there is, we should pick it up. Regards /Ilias > > > > > Regards > > /Ilias > >> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-24 9:05 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-20 6:56 [PATCH net-next v2 0/2] Some minor optimization for page pool Yunsheng Lin 2021-08-20 6:56 ` [PATCH net-next v2 1/2] page_pool: use relaxed atomic for release side accounting Yunsheng Lin 2021-08-20 7:12 ` Jesper Dangaard Brouer 2021-08-20 6:56 ` [PATCH net-next v2 2/2] page_pool: optimize the cpu sync operation when DMA mapping Yunsheng Lin 2021-08-20 9:39 ` Ilias Apalodimas 2021-08-23 3:56 ` Yunsheng Lin 2021-08-23 12:42 ` Ilias Apalodimas 2021-08-24 7:00 ` Yunsheng Lin 2021-08-24 9:04 ` Ilias Apalodimas
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).