All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH net-next v2 0/2] net: mvneta: improve rx performance
Date: Fri, 17 Feb 2017 11:37:21 +0100	[thread overview]
Message-ID: <87shndayse.fsf@free-electrons.com> (raw)
In-Reply-To: <20170217100233.2325-1-jszhang@marvell.com> (Jisheng Zhang's message of "Fri, 17 Feb 2017 18:02:31 +0800")

Hi Jisheng,
 
 On ven., f?vr. 17 2017, Jisheng Zhang <jszhang@marvell.com> wrote:

> In hot code path such as mvneta_rx_hwbm() and mvneta_rx_swbm(), we may
> access fields of rx_desc. The rx_desc is allocated by
> dma_alloc_coherent, it's uncacheable if the device isn't cache
> coherent, reading from uncached memory is fairly slow.

Did you test it with HWBM support?

I am  not sure ti will work in this case.

Gregory

>
> patch1 reuses the read out status to getting status field of rx_desc
> again.
>
> patch2 uses cacheable memory to store the rx buffer DMA address.
>
> We get the following performance data on Marvell BG4CT Platforms
> (tested with iperf):
>
> before the patch:
> recving 1GB in mvneta_rx_swbm() costs 149265960 ns
>
> after the patch:
> recving 1GB in mvneta_rx_swbm() costs 1421565640 ns
>
> We saved 4.76% time.
>
> RFC: can we do similar modification for tx? If yes, I can prepare a v2.
>
>
> Basically, these two patches do what Arnd mentioned in [1].
>
> Hi Arnd,
>
> I added "Suggested-by you" tag, I hope you don't mind ;)
>
> Thanks
>
> [1] https://www.spinics.net/lists/netdev/msg405889.html
>
> Since v1:
>   - correct the performance data typo
>
> Jisheng Zhang (2):
>   net: mvneta: avoid getting status from rx_desc as much as possible
>   net: mvneta: Use cacheable memory to store the rx buffer DMA address
>
>  drivers/net/ethernet/marvell/mvneta.c | 36 ++++++++++++++++++++---------------
>  1 file changed, 21 insertions(+), 15 deletions(-)
>
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Jisheng Zhang <jszhang@marvell.com>
Cc: <thomas.petazzoni@free-electrons.com>, <davem@davemloft.net>,
	<arnd@arndb.de>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next v2 0/2] net: mvneta: improve rx performance
Date: Fri, 17 Feb 2017 11:37:21 +0100	[thread overview]
Message-ID: <87shndayse.fsf@free-electrons.com> (raw)
In-Reply-To: <20170217100233.2325-1-jszhang@marvell.com> (Jisheng Zhang's message of "Fri, 17 Feb 2017 18:02:31 +0800")

Hi Jisheng,
 
 On ven., févr. 17 2017, Jisheng Zhang <jszhang@marvell.com> wrote:

> In hot code path such as mvneta_rx_hwbm() and mvneta_rx_swbm(), we may
> access fields of rx_desc. The rx_desc is allocated by
> dma_alloc_coherent, it's uncacheable if the device isn't cache
> coherent, reading from uncached memory is fairly slow.

Did you test it with HWBM support?

I am  not sure ti will work in this case.

Gregory

>
> patch1 reuses the read out status to getting status field of rx_desc
> again.
>
> patch2 uses cacheable memory to store the rx buffer DMA address.
>
> We get the following performance data on Marvell BG4CT Platforms
> (tested with iperf):
>
> before the patch:
> recving 1GB in mvneta_rx_swbm() costs 149265960 ns
>
> after the patch:
> recving 1GB in mvneta_rx_swbm() costs 1421565640 ns
>
> We saved 4.76% time.
>
> RFC: can we do similar modification for tx? If yes, I can prepare a v2.
>
>
> Basically, these two patches do what Arnd mentioned in [1].
>
> Hi Arnd,
>
> I added "Suggested-by you" tag, I hope you don't mind ;)
>
> Thanks
>
> [1] https://www.spinics.net/lists/netdev/msg405889.html
>
> Since v1:
>   - correct the performance data typo
>
> Jisheng Zhang (2):
>   net: mvneta: avoid getting status from rx_desc as much as possible
>   net: mvneta: Use cacheable memory to store the rx buffer DMA address
>
>  drivers/net/ethernet/marvell/mvneta.c | 36 ++++++++++++++++++++---------------
>  1 file changed, 21 insertions(+), 15 deletions(-)
>
> -- 
> 2.11.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  parent reply	other threads:[~2017-02-17 10:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 10:02 [PATCH net-next v2 0/2] net: mvneta: improve rx performance Jisheng Zhang
2017-02-17 10:02 ` Jisheng Zhang
2017-02-17 10:02 ` [PATCH net-next v2 1/2] net: mvneta: avoid getting status from rx_desc as much as possible Jisheng Zhang
2017-02-17 10:02   ` Jisheng Zhang
2017-02-17 10:02   ` Jisheng Zhang
2017-02-17 13:35   ` Gregory CLEMENT
2017-02-17 13:35     ` Gregory CLEMENT
2017-02-17 10:02 ` [PATCH net-next v2 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address Jisheng Zhang
2017-02-17 10:02   ` Jisheng Zhang
2017-02-17 10:02   ` Jisheng Zhang
2017-02-17 13:30   ` Gregory CLEMENT
2017-02-17 13:30     ` Gregory CLEMENT
2017-02-17 13:55     ` Thomas Petazzoni
2017-02-17 13:55       ` Thomas Petazzoni
2017-02-17 15:20       ` Gregory CLEMENT
2017-02-17 15:20         ` Gregory CLEMENT
2017-02-17 10:09 ` [PATCH net-next v2 0/2] net: mvneta: improve rx performance Jisheng Zhang
2017-02-17 10:09   ` Jisheng Zhang
2017-02-17 10:09   ` Jisheng Zhang
2017-02-17 10:37 ` Gregory CLEMENT [this message]
2017-02-17 10:37   ` Gregory CLEMENT
2017-02-17 10:44   ` Jisheng Zhang
2017-02-17 10:44     ` Jisheng Zhang
2017-02-17 10:44     ` Jisheng Zhang

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=87shndayse.fsf@free-electrons.com \
    --to=gregory.clement@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 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.