[PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API

[PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API

[Lorenzo Bianconi]

Introduce the possibility to sync DMA memory for device in the page_pool API.
This feature allows to sync proper DMA size and not always full buffer
(dma_sync_single_for_device can be very costly).
Please note DMA-sync-for-CPU is still device driver responsibility.
Relying on page_pool DMA sync mvneta driver improves XDP_DROP pps of
about 180Kpps:

- XDP_DROP DMA sync managed by mvneta driver:	~420Kpps
- XDP_DROP DMA sync managed by page_pool API:	~595Kpps

Changes since v2:
- rely on PP_FLAG_DMA_SYNC_DEV flag instead of dma_sync

Changes since v1:
- rename sync in dma_sync
- set dma_sync_size to 0xFFFFFFFF in page_pool_recycle_direct and
  page_pool_put_page routines
- Improve documentation

Lorenzo Bianconi (3):
  net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp
  net: page_pool: add the possibility to sync DMA memory for device
  net: mvneta: get rid of huge dma sync in mvneta_rx_refill

 drivers/net/ethernet/marvell/mvneta.c | 24 +++++++++------
 include/net/page_pool.h               | 21 ++++++++++----
 net/core/page_pool.c                  | 42 +++++++++++++++++++++++----
 3 files changed, 66 insertions(+), 21 deletions(-)

-- 
2.21.0

[PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp

[Lorenzo Bianconi]

Rely on page_pool_recycle_direct and not on xdp_return_buff in
mvneta_run_xdp. This is a preliminary patch to limit the dma sync len
to the one strictly necessary

Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
 drivers/net/ethernet/marvell/mvneta.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 12e03b15f0ab..f7713c2c68e1 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2097,7 +2097,8 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
 		err = xdp_do_redirect(pp->dev, xdp, prog);
 		if (err) {
 			ret = MVNETA_XDP_DROPPED;
-			xdp_return_buff(xdp);
+			page_pool_recycle_direct(rxq->page_pool,
+						 virt_to_head_page(xdp->data));
 		} else {
 			ret = MVNETA_XDP_REDIR;
 		}
@@ -2106,7 +2107,8 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
 	case XDP_TX:
 		ret = mvneta_xdp_xmit_back(pp, xdp);
 		if (ret != MVNETA_XDP_TX)
-			xdp_return_buff(xdp);
+			page_pool_recycle_direct(rxq->page_pool,
+						 virt_to_head_page(xdp->data));
 		break;
 	default:
 		bpf_warn_invalid_xdp_action(act);
-- 
2.21.0

[PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Lorenzo Bianconi]

Introduce the following parameters in order to add the possibility to sync
DMA memory for device before putting allocated pages in the page_pool
caches:
- PP_FLAG_DMA_SYNC_DEV: if set in page_pool_params flags, all pages that
  the driver gets from page_pool will be DMA-synced-for-device according
  to the length provided by the device driver. Please note DMA-sync-for-CPU
  is still device driver responsibility
- offset: DMA address offset where the DMA engine starts copying rx data
- max_len: maximum DMA memory size page_pool is allowed to flush. This
  is currently used in __page_pool_alloc_pages_slow routine when pages
  are allocated from page allocator
These parameters are supposed to be set by device drivers.

This optimization reduces the length of the DMA-sync-for-device.
The optimization is valid because pages are initially
DMA-synced-for-device as defined via max_len. At RX time, the driver
will perform a DMA-sync-for-CPU on the memory for the packet length.
What is important is the memory occupied by packet payload, because
this is the area CPU is allowed to read and modify. As we don't track
cache-lines written into by the CPU, simply use the packet payload length
as dma_sync_size at page_pool recycle time. This also take into account
any tail-extend.

Tested-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
 include/net/page_pool.h | 21 +++++++++++++++------
 net/core/page_pool.c    | 42 +++++++++++++++++++++++++++++++++++------
 2 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/include/net/page_pool.h b/include/net/page_pool.h
index 2cbcdbdec254..8856d2c815d0 100644
--- a/include/net/page_pool.h
+++ b/include/net/page_pool.h
@@ -34,8 +34,15 @@
 #include <linux/ptr_ring.h>
 #include <linux/dma-direction.h>
 
-#define PP_FLAG_DMA_MAP 1 /* Should page_pool do the DMA map/unmap */
-#define PP_FLAG_ALL	PP_FLAG_DMA_MAP
+#define PP_FLAG_DMA_MAP		1 /* Should page_pool do the DMA map/unmap */
+#define PP_FLAG_DMA_SYNC_DEV	2 /* if set all pages that the driver gets
+				   * from page_pool will be
+				   * DMA-synced-for-device according to the
+				   * length provided by the device driver.
+				   * Please note DMA-sync-for-CPU is still
+				   * device driver responsibility
+				   */
+#define PP_FLAG_ALL		(PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV)
 
 /*
  * Fast allocation side cache array/stack
@@ -65,6 +72,8 @@ struct page_pool_params {
 	int		nid;  /* Numa node id to allocate from pages from */
 	struct device	*dev; /* device, for DMA pre-mapping purposes */
 	enum dma_data_direction dma_dir; /* DMA mapping direction */
+	unsigned int	max_len; /* max DMA sync memory size */
+	unsigned int	offset;  /* DMA addr offset */
 };
 
 struct page_pool {
@@ -150,8 +159,8 @@ static inline void page_pool_destroy(struct page_pool *pool)
 }
 
 /* Never call this directly, use helpers below */
-void __page_pool_put_page(struct page_pool *pool,
-			  struct page *page, bool allow_direct);
+void __page_pool_put_page(struct page_pool *pool, struct page *page,
+			  unsigned int dma_sync_size, bool allow_direct);
 
 static inline void page_pool_put_page(struct page_pool *pool,
 				      struct page *page, bool allow_direct)
@@ -160,14 +169,14 @@ static inline void page_pool_put_page(struct page_pool *pool,
 	 * allow registering MEM_TYPE_PAGE_POOL, but shield linker.
 	 */
 #ifdef CONFIG_PAGE_POOL
-	__page_pool_put_page(pool, page, allow_direct);
+	__page_pool_put_page(pool, page, -1, allow_direct);
 #endif
 }
 /* Very limited use-cases allow recycle direct */
 static inline void page_pool_recycle_direct(struct page_pool *pool,
 					    struct page *page)
 {
-	__page_pool_put_page(pool, page, true);
+	__page_pool_put_page(pool, page, -1, true);
 }
 
 /* API user MUST have disconnected alloc-side (not allowed to call
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 5bc65587f1c4..e4ea607f2098 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -44,6 +44,13 @@ static int page_pool_init(struct page_pool *pool,
 	    (pool->p.dma_dir != DMA_BIDIRECTIONAL))
 		return -EINVAL;
 
+	/* In order to request DMA-sync-for-device the page needs to
+	 * be mapped
+	 */
+	if ((pool->p.flags & PP_FLAG_DMA_SYNC_DEV) &&
+	    !(pool->p.flags & PP_FLAG_DMA_MAP))
+		return -EINVAL;
+
 	if (ptr_ring_init(&pool->ring, ring_qsize, GFP_KERNEL) < 0)
 		return -ENOMEM;
 
@@ -112,6 +119,16 @@ static struct page *__page_pool_get_cached(struct page_pool *pool)
 	return page;
 }
 
+static void page_pool_dma_sync_for_device(struct page_pool *pool,
+					  struct page *page,
+					  unsigned int dma_sync_size)
+{
+	dma_sync_size = min(dma_sync_size, pool->p.max_len);
+	dma_sync_single_range_for_device(pool->p.dev, page->dma_addr,
+					 pool->p.offset, dma_sync_size,
+					 pool->p.dma_dir);
+}
+
 /* slow path */
 noinline
 static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
@@ -156,6 +173,9 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
 	}
 	page->dma_addr = dma;
 
+	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
+		page_pool_dma_sync_for_device(pool, page, pool->p.max_len);
+
 skip_dma_map:
 	/* Track how many pages are held 'in-flight' */
 	pool->pages_state_hold_cnt++;
@@ -255,7 +275,8 @@ static void __page_pool_return_page(struct page_pool *pool, struct page *page)
 }
 
 static bool __page_pool_recycle_into_ring(struct page_pool *pool,
-				   struct page *page)
+					  struct page *page,
+					  unsigned int dma_sync_size)
 {
 	int ret;
 	/* BH protection not needed if current is serving softirq */
@@ -264,6 +285,9 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
 	else
 		ret = ptr_ring_produce_bh(&pool->ring, page);
 
+	if (ret == 0 && (pool->p.flags & PP_FLAG_DMA_SYNC_DEV))
+		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
+
 	return (ret == 0) ? true : false;
 }
 
@@ -273,18 +297,22 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
  * Caller must provide appropriate safe context.
  */
 static bool __page_pool_recycle_direct(struct page *page,
-				       struct page_pool *pool)
+				       struct page_pool *pool,
+				       unsigned int dma_sync_size)
 {
 	if (unlikely(pool->alloc.count == PP_ALLOC_CACHE_SIZE))
 		return false;
 
 	/* Caller MUST have verified/know (page_ref_count(page) == 1) */
 	pool->alloc.cache[pool->alloc.count++] = page;
+
+	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
+		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
 	return true;
 }
 
-void __page_pool_put_page(struct page_pool *pool,
-			  struct page *page, bool allow_direct)
+void __page_pool_put_page(struct page_pool *pool, struct page *page,
+			  unsigned int dma_sync_size, bool allow_direct)
 {
 	/* This allocator is optimized for the XDP mode that uses
 	 * one-frame-per-page, but have fallbacks that act like the
@@ -296,10 +324,12 @@ void __page_pool_put_page(struct page_pool *pool,
 		/* Read barrier done in page_ref_count / READ_ONCE */
 
 		if (allow_direct && in_serving_softirq())
-			if (__page_pool_recycle_direct(page, pool))
+			if (__page_pool_recycle_direct(page, pool,
+						       dma_sync_size))
 				return;
 
-		if (!__page_pool_recycle_into_ring(pool, page)) {
+		if (!__page_pool_recycle_into_ring(pool, page,
+						   dma_sync_size)) {
 			/* Cache full, fallback to free pages */
 			__page_pool_return_page(pool, page);
 		}
-- 
2.21.0

Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Jonathan Lemon]

On 15 Nov 2019, at 11:01, Lorenzo Bianconi wrote:

> Introduce the following parameters in order to add the possibility to sync
> DMA memory for device before putting allocated pages in the page_pool
> caches:
> - PP_FLAG_DMA_SYNC_DEV: if set in page_pool_params flags, all pages that
>   the driver gets from page_pool will be DMA-synced-for-device according
>   to the length provided by the device driver. Please note DMA-sync-for-CPU
>   is still device driver responsibility
> - offset: DMA address offset where the DMA engine starts copying rx data
> - max_len: maximum DMA memory size page_pool is allowed to flush. This
>   is currently used in __page_pool_alloc_pages_slow routine when pages
>   are allocated from page allocator
> These parameters are supposed to be set by device drivers.
>
> This optimization reduces the length of the DMA-sync-for-device.
> The optimization is valid because pages are initially
> DMA-synced-for-device as defined via max_len. At RX time, the driver
> will perform a DMA-sync-for-CPU on the memory for the packet length.
> What is important is the memory occupied by packet payload, because
> this is the area CPU is allowed to read and modify. As we don't track
> cache-lines written into by the CPU, simply use the packet payload length
> as dma_sync_size at page_pool recycle time. This also take into account
> any tail-extend.
>
> Tested-by: Matteo Croce <mcroce@redhat.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>

Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>

Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Jesper Dangaard Brouer]

On Fri, 15 Nov 2019 21:01:38 +0200
Lorenzo Bianconi <lorenzo@kernel.org> wrote:

>  static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> -				   struct page *page)
> +					  struct page *page,
> +					  unsigned int dma_sync_size)
>  {
>  	int ret;
>  	/* BH protection not needed if current is serving softirq */
> @@ -264,6 +285,9 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
>  	else
>  		ret = ptr_ring_produce_bh(&pool->ring, page);
>  
> +	if (ret == 0 && (pool->p.flags & PP_FLAG_DMA_SYNC_DEV))
> +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> +
>  	return (ret == 0) ? true : false;
>  }


I do wonder if we should DMA-sync-for-device BEFORE putting page into
ptr_ring, as this is a channel between several concurrent CPUs.



> @@ -273,18 +297,22 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
>   * Caller must provide appropriate safe context.
>   */
>  static bool __page_pool_recycle_direct(struct page *page,
> -				       struct page_pool *pool)
> +				       struct page_pool *pool,
> +				       unsigned int dma_sync_size)
>  {
>  	if (unlikely(pool->alloc.count == PP_ALLOC_CACHE_SIZE))
>  		return false;
>  
>  	/* Caller MUST have verified/know (page_ref_count(page) == 1) */
>  	pool->alloc.cache[pool->alloc.count++] = page;
> +
> +	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
>  	return true;
>  }

We know __page_pool_recycle_direct() is concurrency safe, and only a
single (NAPI processing) CPU can enter. (So, the DMA-sync order is not
wrong here, but it could be swapped)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

> On Fri, 15 Nov 2019 21:01:38 +0200
> Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> 
> >  static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > -				   struct page *page)
> > +					  struct page *page,
> > +					  unsigned int dma_sync_size)
> >  {
> >  	int ret;
> >  	/* BH protection not needed if current is serving softirq */
> > @@ -264,6 +285,9 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> >  	else
> >  		ret = ptr_ring_produce_bh(&pool->ring, page);
> >  
> > +	if (ret == 0 && (pool->p.flags & PP_FLAG_DMA_SYNC_DEV))
> > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> > +
> >  	return (ret == 0) ? true : false;
> >  }
> 
> 
> I do wonder if we should DMA-sync-for-device BEFORE putting page into
> ptr_ring, as this is a channel between several concurrent CPUs.

Hi Jesper,

in this way we can end up syncing the DMA page even if it is unmapped in
__page_pool_clean_page (e.g. if the ptr_ring is full), right?

> 
> 
> 
> > @@ -273,18 +297,22 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> >   * Caller must provide appropriate safe context.
> >   */
> >  static bool __page_pool_recycle_direct(struct page *page,
> > -				       struct page_pool *pool)
> > +				       struct page_pool *pool,
> > +				       unsigned int dma_sync_size)
> >  {
> >  	if (unlikely(pool->alloc.count == PP_ALLOC_CACHE_SIZE))
> >  		return false;
> >  
> >  	/* Caller MUST have verified/know (page_ref_count(page) == 1) */
> >  	pool->alloc.cache[pool->alloc.count++] = page;
> > +
> > +	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> >  	return true;
> >  }
> 
> We know __page_pool_recycle_direct() is concurrency safe, and only a
> single (NAPI processing) CPU can enter. (So, the DMA-sync order is not
> wrong here, but it could be swapped)

do you mean move it before putting the page in the cache?

pool->alloc.cache[pool->alloc.count++] = page;

Regards,
Lorenzo

> 
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Jesper Dangaard Brouer]

On Sat, 16 Nov 2019 13:36:30 +0200
Lorenzo Bianconi <lorenzo@kernel.org> wrote:

> > On Fri, 15 Nov 2019 21:01:38 +0200
> > Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> >   
> > >  static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > > -				   struct page *page)
> > > +					  struct page *page,
> > > +					  unsigned int dma_sync_size)
> > >  {
> > >  	int ret;
> > >  	/* BH protection not needed if current is serving softirq */
> > > @@ -264,6 +285,9 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > >  	else
> > >  		ret = ptr_ring_produce_bh(&pool->ring, page);
> > >  
> > > +	if (ret == 0 && (pool->p.flags & PP_FLAG_DMA_SYNC_DEV))
> > > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> > > +
> > >  	return (ret == 0) ? true : false;
> > >  }  
> > 
> > 
> > I do wonder if we should DMA-sync-for-device BEFORE putting page into
> > ptr_ring, as this is a channel between several concurrent CPUs.  
> 
> Hi Jesper,
> 
> in this way we can end up syncing the DMA page even if it is unmapped in
> __page_pool_clean_page (e.g. if the ptr_ring is full), right?

Yes.  The call __page_pool_clean_page() will do a dma_unmap_page, so it
should still be safe/correct.   I can see, that it is not optimal
performance wise, in-case the ptr_ring is full, as DMA-sync-for-device
is wasted work.

I don't know if you can find an argument, that proves that it cannot
happen, that a remote CPU can dequeue/consume the page from ptr_ring
and give it to the device, while you (the CPU the enqueued) are still
doing the DMA-sync-for-device.

 
> > > @@ -273,18 +297,22 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > >   * Caller must provide appropriate safe context.
> > >   */
> > >  static bool __page_pool_recycle_direct(struct page *page,
> > > -				       struct page_pool *pool)
> > > +				       struct page_pool *pool,
> > > +				       unsigned int dma_sync_size)
> > >  {
> > >  	if (unlikely(pool->alloc.count == PP_ALLOC_CACHE_SIZE))
> > >  		return false;
> > >  
> > >  	/* Caller MUST have verified/know (page_ref_count(page) == 1) */
> > >  	pool->alloc.cache[pool->alloc.count++] = page;
> > > +
> > > +	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> > > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> > >  	return true;
> > >  }  
> > 
> > We know __page_pool_recycle_direct() is concurrency safe, and only a
> > single (NAPI processing) CPU can enter. (So, the DMA-sync order is not
> > wrong here, but it could be swapped)  
> 
> do you mean move it before putting the page in the cache?
> 
> pool->alloc.cache[pool->alloc.count++] = page;

Yes, but here the order doesn't matter.

If you choose to do the DMA-sync-for-device earlier/before, then look
at the code, and see of it makes sense to do it in __page_pool_put_page() ?
(I've not checked the details)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device

[Lorenzo Bianconi]

[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]

> On Sat, 16 Nov 2019 13:36:30 +0200
> Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> 
> > > On Fri, 15 Nov 2019 21:01:38 +0200
> > > Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> > >   
> > > >  static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > > > -				   struct page *page)
> > > > +					  struct page *page,
> > > > +					  unsigned int dma_sync_size)
> > > >  {
> > > >  	int ret;
> > > >  	/* BH protection not needed if current is serving softirq */
> > > > @@ -264,6 +285,9 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > > >  	else
> > > >  		ret = ptr_ring_produce_bh(&pool->ring, page);
> > > >  
> > > > +	if (ret == 0 && (pool->p.flags & PP_FLAG_DMA_SYNC_DEV))
> > > > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> > > > +
> > > >  	return (ret == 0) ? true : false;
> > > >  }  
> > > 
> > > 
> > > I do wonder if we should DMA-sync-for-device BEFORE putting page into
> > > ptr_ring, as this is a channel between several concurrent CPUs.  
> > 
> > Hi Jesper,
> > 
> > in this way we can end up syncing the DMA page even if it is unmapped in
> > __page_pool_clean_page (e.g. if the ptr_ring is full), right?
> 
> Yes.  The call __page_pool_clean_page() will do a dma_unmap_page, so it
> should still be safe/correct.   I can see, that it is not optimal
> performance wise, in-case the ptr_ring is full, as DMA-sync-for-device
> is wasted work.
> 
> I don't know if you can find an argument, that proves that it cannot
> happen, that a remote CPU can dequeue/consume the page from ptr_ring
> and give it to the device, while you (the CPU the enqueued) are still
> doing the DMA-sync-for-device.

right, I can see it now :)

> 
>  
> > > > @@ -273,18 +297,22 @@ static bool __page_pool_recycle_into_ring(struct page_pool *pool,
> > > >   * Caller must provide appropriate safe context.
> > > >   */
> > > >  static bool __page_pool_recycle_direct(struct page *page,
> > > > -				       struct page_pool *pool)
> > > > +				       struct page_pool *pool,
> > > > +				       unsigned int dma_sync_size)
> > > >  {
> > > >  	if (unlikely(pool->alloc.count == PP_ALLOC_CACHE_SIZE))
> > > >  		return false;
> > > >  
> > > >  	/* Caller MUST have verified/know (page_ref_count(page) == 1) */
> > > >  	pool->alloc.cache[pool->alloc.count++] = page;
> > > > +
> > > > +	if (pool->p.flags & PP_FLAG_DMA_SYNC_DEV)
> > > > +		page_pool_dma_sync_for_device(pool, page, dma_sync_size);
> > > >  	return true;
> > > >  }  
> > > 
> > > We know __page_pool_recycle_direct() is concurrency safe, and only a
> > > single (NAPI processing) CPU can enter. (So, the DMA-sync order is not
> > > wrong here, but it could be swapped)  
> > 
> > do you mean move it before putting the page in the cache?
> > 
> > pool->alloc.cache[pool->alloc.count++] = page;
> 
> Yes, but here the order doesn't matter.
> 
> If you choose to do the DMA-sync-for-device earlier/before, then look
> at the code, and see of it makes sense to do it in __page_pool_put_page() ?
> (I've not checked the details)

I guess we can move page_pool_dma_sync_for_device() before
__page_pool_recycle_direct and __page_pool_recycle_into_ring since even if
__page_pool_put_page is not running in NAPI context or if alloc.cache is full
we will end up calling page_pool_dma_sync_for_device as first task in
__page_pool_recycle_into_ring. I will fix in v4.

Regards,
Lorenzo

> 
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v3 net-next 3/3] net: mvneta: get rid of huge dma sync in mvneta_rx_refill

[Lorenzo Bianconi]

Get rid of costly dma_sync_single_for_device in mvneta_rx_refill
since now the driver can let page_pool API to manage needed DMA
sync with a proper size.

- XDP_DROP DMA sync managed by mvneta driver:	~420Kpps
- XDP_DROP DMA sync managed by page_pool API:	~595Kpps

Tested-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
 drivers/net/ethernet/marvell/mvneta.c | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index f7713c2c68e1..a06d109c9e80 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1846,7 +1846,6 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
 			    struct mvneta_rx_queue *rxq,
 			    gfp_t gfp_mask)
 {
-	enum dma_data_direction dma_dir;
 	dma_addr_t phys_addr;
 	struct page *page;
 
@@ -1856,9 +1855,6 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
 		return -ENOMEM;
 
 	phys_addr = page_pool_get_dma_addr(page) + pp->rx_offset_correction;
-	dma_dir = page_pool_get_dma_dir(rxq->page_pool);
-	dma_sync_single_for_device(pp->dev->dev.parent, phys_addr,
-				   MVNETA_MAX_RX_BUF_SIZE, dma_dir);
 	mvneta_rx_desc_fill(rx_desc, phys_addr, page, rxq);
 
 	return 0;
@@ -2097,8 +2093,10 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
 		err = xdp_do_redirect(pp->dev, xdp, prog);
 		if (err) {
 			ret = MVNETA_XDP_DROPPED;
-			page_pool_recycle_direct(rxq->page_pool,
-						 virt_to_head_page(xdp->data));
+			__page_pool_put_page(rxq->page_pool,
+					virt_to_head_page(xdp->data),
+					xdp->data_end - xdp->data_hard_start,
+					true);
 		} else {
 			ret = MVNETA_XDP_REDIR;
 		}
@@ -2107,8 +2105,10 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
 	case XDP_TX:
 		ret = mvneta_xdp_xmit_back(pp, xdp);
 		if (ret != MVNETA_XDP_TX)
-			page_pool_recycle_direct(rxq->page_pool,
-						 virt_to_head_page(xdp->data));
+			__page_pool_put_page(rxq->page_pool,
+					virt_to_head_page(xdp->data),
+					xdp->data_end - xdp->data_hard_start,
+					true);
 		break;
 	default:
 		bpf_warn_invalid_xdp_action(act);
@@ -2117,8 +2117,10 @@ mvneta_run_xdp(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
 		trace_xdp_exception(pp->dev, prog, act);
 		/* fall through */
 	case XDP_DROP:
-		page_pool_recycle_direct(rxq->page_pool,
-					 virt_to_head_page(xdp->data));
+		__page_pool_put_page(rxq->page_pool,
+				     virt_to_head_page(xdp->data),
+				     xdp->data_end - xdp->data_hard_start,
+				     true);
 		ret = MVNETA_XDP_DROPPED;
 		break;
 	}
@@ -3067,11 +3069,13 @@ static int mvneta_create_page_pool(struct mvneta_port *pp,
 	struct bpf_prog *xdp_prog = READ_ONCE(pp->xdp_prog);
 	struct page_pool_params pp_params = {
 		.order = 0,
-		.flags = PP_FLAG_DMA_MAP,
+		.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
 		.pool_size = size,
 		.nid = cpu_to_node(0),
 		.dev = pp->dev->dev.parent,
 		.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE,
+		.offset = pp->rx_offset_correction,
+		.max_len = MVNETA_MAX_RX_BUF_SIZE,
 	};
 	int err;
 
-- 
2.21.0