From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org
Cc: brouer@redhat.com, almasrymina@google.com, hawk@kernel.org,
ilias.apalodimas@linaro.org, edumazet@google.com,
dsahern@gmail.com, michael.chan@broadcom.com, willemb@google.com
Subject: Re: [RFC 08/12] eth: bnxt: let the page pool manage the DMA mapping
Date: Mon, 10 Jul 2023 12:12:29 +0200 [thread overview]
Message-ID: <f8270765-a27b-6ccf-33ea-cda097168d79@redhat.com> (raw)
In-Reply-To: <20230707183935.997267-9-kuba@kernel.org>
On 07/07/2023 20.39, Jakub Kicinski wrote:
> Use the page pool's ability to maintain DMA mappings for us.
> This avoid re-mapping recycled pages.
>
For DMA using IOMMU mappings, using page_pool like this patch solves the
main bottleneck. Thus, I suspect this patch will give the biggest
performance boost on it's own.
As you have already discovered, the next bottleneck then becomes the
IOMMU's address resolution, which the IOTLB (I/O Translation Lookaside
Buffer) hardware helps speed up.
There are a number of techniques for reducing IOTLB misses.
I recommend reading:
IOMMU: Strategies for Mitigating the IOTLB Bottleneck
- https://inria.hal.science/inria-00493752/document
> Note that pages in the pool are always mapped DMA_BIDIRECTIONAL,
> so we should use that instead of looking at bp->rx_dir.
>
> The syncing is probably wrong, TBH, I haven't studied the page
> pool rules, they always confused me. But for a hack, who cares,
> x86 :D
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 24 ++++++++---------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Love seeing these stats, where page_pool reduce lines in drivers.
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index e5b54e6025be..6512514cd498 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> @@ -706,12 +706,9 @@ static struct page *__bnxt_alloc_rx_page(struct bnxt *bp, dma_addr_t *mapping,
> if (!page)
> return NULL;
>
> - *mapping = dma_map_page_attrs(dev, page, 0, PAGE_SIZE, bp->rx_dir,
> - DMA_ATTR_WEAK_ORDERING);
> - if (dma_mapping_error(dev, *mapping)) {
> - page_pool_recycle_direct(rxr->page_pool, page);
> - return NULL;
> - }
> + *mapping = page_pool_get_dma_addr(page);
> + dma_sync_single_for_device(dev, *mapping, PAGE_SIZE, DMA_BIDIRECTIONAL);
> +
You can keep this as-is, but I just wanted mention that page_pool
supports doing the "dma_sync_for_device" via PP_FLAG_DMA_SYNC_DEV.
Thus, removing more lines from driver code.
> return page;
> }
>
> @@ -951,6 +948,7 @@ static struct sk_buff *bnxt_rx_multi_page_skb(struct bnxt *bp,
> unsigned int offset_and_len)
> {
> unsigned int len = offset_and_len & 0xffff;
> + struct device *dev = &bp->pdev->dev;
> struct page *page = data;
> u16 prod = rxr->rx_prod;
> struct sk_buff *skb;
> @@ -962,8 +960,7 @@ static struct sk_buff *bnxt_rx_multi_page_skb(struct bnxt *bp,
> return NULL;
> }
> dma_addr -= bp->rx_dma_offset;
> - dma_unmap_page_attrs(&bp->pdev->dev, dma_addr, PAGE_SIZE, bp->rx_dir,
> - DMA_ATTR_WEAK_ORDERING);
> + dma_sync_single_for_cpu(dev, dma_addr, PAGE_SIZE, DMA_BIDIRECTIONAL);
> skb = build_skb(page_address(page), PAGE_SIZE);
> if (!skb) {
> page_pool_recycle_direct(rxr->page_pool, page);
> @@ -984,6 +981,7 @@ static struct sk_buff *bnxt_rx_page_skb(struct bnxt *bp,
> {
> unsigned int payload = offset_and_len >> 16;
> unsigned int len = offset_and_len & 0xffff;
> + struct device *dev = &bp->pdev->dev;
> skb_frag_t *frag;
> struct page *page = data;
> u16 prod = rxr->rx_prod;
> @@ -996,8 +994,7 @@ static struct sk_buff *bnxt_rx_page_skb(struct bnxt *bp,
> return NULL;
> }
> dma_addr -= bp->rx_dma_offset;
> - dma_unmap_page_attrs(&bp->pdev->dev, dma_addr, PAGE_SIZE, bp->rx_dir,
> - DMA_ATTR_WEAK_ORDERING);
> + dma_sync_single_for_cpu(dev, dma_addr, PAGE_SIZE, DMA_BIDIRECTIONAL);
>
> if (unlikely(!payload))
> payload = eth_get_headlen(bp->dev, data_ptr, len);
> @@ -2943,9 +2940,6 @@ static void bnxt_free_one_rx_ring_skbs(struct bnxt *bp, int ring_nr)
> rx_buf->data = NULL;
> if (BNXT_RX_PAGE_MODE(bp)) {
> mapping -= bp->rx_dma_offset;
> - dma_unmap_page_attrs(&pdev->dev, mapping, PAGE_SIZE,
> - bp->rx_dir,
> - DMA_ATTR_WEAK_ORDERING);
> page_pool_recycle_direct(rxr->page_pool, data);
> } else {
> dma_unmap_single_attrs(&pdev->dev, mapping,
> @@ -2967,9 +2961,6 @@ static void bnxt_free_one_rx_ring_skbs(struct bnxt *bp, int ring_nr)
> continue;
>
> if (BNXT_RX_PAGE_MODE(bp)) {
> - dma_unmap_page_attrs(&pdev->dev, rx_agg_buf->mapping,
> - BNXT_RX_PAGE_SIZE, bp->rx_dir,
> - DMA_ATTR_WEAK_ORDERING);
> rx_agg_buf->page = NULL;
> __clear_bit(i, rxr->rx_agg_bmap);
>
> @@ -3208,6 +3199,7 @@ static int bnxt_alloc_rx_page_pool(struct bnxt *bp,
> {
> struct page_pool_params pp = { 0 };
>
> + pp.flags = PP_FLAG_DMA_MAP;
> pp.pool_size = bp->rx_ring_size;
> pp.nid = dev_to_node(&bp->pdev->dev);
> pp.napi = &rxr->bnapi->napi;
next prev parent reply other threads:[~2023-07-10 10:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 18:39 [RFC 00/12] net: huge page backed page_pool Jakub Kicinski
2023-07-07 18:39 ` [RFC 01/12] net: hack together some page sharing Jakub Kicinski
2023-07-07 18:39 ` [RFC 02/12] net: create a 1G-huge-page-backed allocator Jakub Kicinski
2023-07-07 18:39 ` [RFC 03/12] net: page_pool: hide page_pool_release_page() Jakub Kicinski
2023-07-07 18:39 ` [RFC 04/12] net: page_pool: merge page_pool_release_page() with page_pool_return_page() Jakub Kicinski
2023-07-10 16:07 ` Jesper Dangaard Brouer
2023-07-07 18:39 ` [RFC 05/12] net: page_pool: factor out releasing DMA from releasing the page Jakub Kicinski
2023-07-07 18:39 ` [RFC 06/12] net: page_pool: create hooks for custom page providers Jakub Kicinski
2023-07-07 19:50 ` Mina Almasry
2023-07-07 22:28 ` Jakub Kicinski
2023-07-07 18:39 ` [RFC 07/12] net: page_pool: add huge page backed memory providers Jakub Kicinski
2023-07-07 18:39 ` [RFC 08/12] eth: bnxt: let the page pool manage the DMA mapping Jakub Kicinski
2023-07-10 10:12 ` Jesper Dangaard Brouer [this message]
2023-07-26 6:56 ` Ilias Apalodimas
2023-07-07 18:39 ` [RFC 09/12] eth: bnxt: use the page pool for data pages Jakub Kicinski
2023-07-10 4:22 ` Michael Chan
2023-07-10 17:04 ` Jakub Kicinski
2023-07-07 18:39 ` [RFC 10/12] eth: bnxt: make sure we make for recycle skbs before freeing them Jakub Kicinski
2023-07-07 18:39 ` [RFC 11/12] eth: bnxt: wrap coherent allocations into helpers Jakub Kicinski
2023-07-07 18:39 ` [RFC 12/12] eth: bnxt: hack in the use of MEP Jakub Kicinski
2023-07-07 19:45 ` [RFC 00/12] net: huge page backed page_pool Mina Almasry
2023-07-07 22:45 ` Jakub Kicinski
2023-07-10 17:31 ` Mina Almasry
2023-07-11 15:49 ` Jesper Dangaard Brouer
2023-07-12 0:08 ` Jakub Kicinski
2023-07-12 11:47 ` Yunsheng Lin
2023-07-12 12:43 ` Jesper Dangaard Brouer
2023-07-12 17:01 ` Jakub Kicinski
2023-07-14 13:05 ` Yunsheng Lin
2023-07-12 14:00 ` Jesper Dangaard Brouer
2023-07-12 17:19 ` Jakub Kicinski
2023-07-13 10:07 ` Jesper Dangaard Brouer
2023-07-13 16:27 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f8270765-a27b-6ccf-33ea-cda097168d79@redhat.com \
--to=jbrouer@redhat.com \
--cc=almasrymina@google.com \
--cc=brouer@redhat.com \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).