netdev - Re: [PATCH net-next] mvpp2: prefetch frame header

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20191023.202813.607713311547571229.davem@davemloft.net>
Date:   Wed, 23 Oct 2019 20:28:13 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     mcroce@...hat.com
Cc:     netdev@...r.kernel.org, antoine.tenart@...tlin.com,
        maxime.chevallier@...tlin.com, mw@...ihalf.com,
        stefanc@...vell.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] mvpp2: prefetch frame header

From: Matteo Croce <mcroce@...hat.com>
Date: Tue, 22 Oct 2019 16:14:38 +0200

> When receiving traffic, eth_type_trans() is high up on the perf top list,
> because it's the first function which access the packet data.
> 
> Move the DMA unmap a bit higher, and put a prefetch just after it, so we
> have more time to load the data into the cache.
> 
> The packet rate increase is about 13% with a tc drop test: 1620 => 1830 kpps
> 
> Signed-off-by: Matteo Croce <mcroce@...hat.com>
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 111b3b8239e1..17378e0d8da1 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -2966,6 +2966,11 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  			continue;
>  		}
>  
> +		dma_unmap_single(dev->dev.parent, dma_addr,
> +				 bm_pool->buf_size, DMA_FROM_DEVICE);
> +
> +		prefetch(data);
> +
>  		if (bm_pool->frag_size > PAGE_SIZE)
>  			frag_size = 0;
>  		else

You cannot unmap it this early, because of all of the err_drop_frame
code paths that might be taken next.  The DMA mapping must stay in place
in those cases.