* [PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API @ 2019-11-15 19:01 Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp Lorenzo Bianconi ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-15 19:01 UTC (permalink / raw) To: netdev; +Cc: davem, ilias.apalodimas, brouer, lorenzo.bianconi, mcroce 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp 2019-11-15 19:01 [PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API Lorenzo Bianconi @ 2019-11-15 19:01 ` Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 3/3] net: mvneta: get rid of huge dma sync in mvneta_rx_refill Lorenzo Bianconi 2 siblings, 0 replies; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-15 19:01 UTC (permalink / raw) To: netdev; +Cc: davem, ilias.apalodimas, brouer, lorenzo.bianconi, mcroce 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-15 19:01 [PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp Lorenzo Bianconi @ 2019-11-15 19:01 ` Lorenzo Bianconi 2019-11-15 19:35 ` Jonathan Lemon 2019-11-16 11:20 ` Jesper Dangaard Brouer 2019-11-15 19:01 ` [PATCH v3 net-next 3/3] net: mvneta: get rid of huge dma sync in mvneta_rx_refill Lorenzo Bianconi 2 siblings, 2 replies; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-15 19:01 UTC (permalink / raw) To: netdev; +Cc: davem, ilias.apalodimas, brouer, lorenzo.bianconi, mcroce 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-15 19:01 ` [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device Lorenzo Bianconi @ 2019-11-15 19:35 ` Jonathan Lemon 2019-11-16 11:20 ` Jesper Dangaard Brouer 1 sibling, 0 replies; 9+ messages in thread From: Jonathan Lemon @ 2019-11-15 19:35 UTC (permalink / raw) To: Lorenzo Bianconi Cc: netdev, davem, ilias.apalodimas, brouer, lorenzo.bianconi, mcroce 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> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-15 19:01 ` [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device Lorenzo Bianconi 2019-11-15 19:35 ` Jonathan Lemon @ 2019-11-16 11:20 ` Jesper Dangaard Brouer 2019-11-16 11:36 ` Lorenzo Bianconi 1 sibling, 1 reply; 9+ messages in thread From: Jesper Dangaard Brouer @ 2019-11-16 11:20 UTC (permalink / raw) To: Lorenzo Bianconi Cc: netdev, davem, ilias.apalodimas, lorenzo.bianconi, mcroce, 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-16 11:20 ` Jesper Dangaard Brouer @ 2019-11-16 11:36 ` Lorenzo Bianconi 2019-11-16 12:17 ` Jesper Dangaard Brouer 0 siblings, 1 reply; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-16 11:36 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: netdev, davem, ilias.apalodimas, lorenzo.bianconi, mcroce [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-16 11:36 ` Lorenzo Bianconi @ 2019-11-16 12:17 ` Jesper Dangaard Brouer 2019-11-16 14:17 ` Lorenzo Bianconi 0 siblings, 1 reply; 9+ messages in thread From: Jesper Dangaard Brouer @ 2019-11-16 12:17 UTC (permalink / raw) To: Lorenzo Bianconi Cc: netdev, davem, ilias.apalodimas, lorenzo.bianconi, mcroce, 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device 2019-11-16 12:17 ` Jesper Dangaard Brouer @ 2019-11-16 14:17 ` Lorenzo Bianconi 0 siblings, 0 replies; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-16 14:17 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: netdev, davem, ilias.apalodimas, lorenzo.bianconi, mcroce [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3 net-next 3/3] net: mvneta: get rid of huge dma sync in mvneta_rx_refill 2019-11-15 19:01 [PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device Lorenzo Bianconi @ 2019-11-15 19:01 ` Lorenzo Bianconi 2 siblings, 0 replies; 9+ messages in thread From: Lorenzo Bianconi @ 2019-11-15 19:01 UTC (permalink / raw) To: netdev; +Cc: davem, ilias.apalodimas, brouer, lorenzo.bianconi, mcroce 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-16 14:17 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-15 19:01 [PATCH v3 net-next 0/3] add DMA-sync-for-device capability to page_pool API Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 1/3] net: mvneta: rely on page_pool_recycle_direct in mvneta_run_xdp Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 2/3] net: page_pool: add the possibility to sync DMA memory for device Lorenzo Bianconi 2019-11-15 19:35 ` Jonathan Lemon 2019-11-16 11:20 ` Jesper Dangaard Brouer 2019-11-16 11:36 ` Lorenzo Bianconi 2019-11-16 12:17 ` Jesper Dangaard Brouer 2019-11-16 14:17 ` Lorenzo Bianconi 2019-11-15 19:01 ` [PATCH v3 net-next 3/3] net: mvneta: get rid of huge dma sync in mvneta_rx_refill Lorenzo Bianconi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.