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 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address
Date: Fri, 17 Feb 2017 16:20:34 +0100	[thread overview]
Message-ID: <87fujcc08t.fsf@free-electrons.com> (raw)
In-Reply-To: <20170217145501.5b90a977@free-electrons.com> (Thomas Petazzoni's message of "Fri, 17 Feb 2017 14:55:01 +0100")

Hi Thomas,
 
 On ven., f?vr. 17 2017, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Does not make sense, because it's not the SW that refills the RX
> descriptors with the address of the RX buffers. It's done by the HW.
>
> With HWBM, I believe you have no choice but to read the physical
> address from the RX descriptor. But you can probably optimize things a
> little bit by reading it only once, and then storing it into a
> cacheable variable.
>
> So maybe:
>
>  - For SWBM, use the strategy proposed by Jisheng
>  - For HWBM, at the beginning of the RX completion path, read once the
>    rx_desc->buf_phys_addr, and store it in rxq->buf_dma_addr[index]


For the HWBM path storing rx_desc->buf_phys_addr in
rxq->buf_dma_addr[index] is not useful as we only use it in a single
function.

But a quick improvement could be to use the phys_addr variable. Indeed
we store the value of rx_desc->buf_phys_addr in it and we never used it,
instead we always use rx_desc->buf_phys_addr.

Gregory

>
> Of course that's just a very rough proposal. I've been looking mainly
> at mvpp2 lately, and I'm not sure I still remember how mvneta works in
> the details.
>
> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jisheng Zhang <jszhang@marvell.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 2/2] net: mvneta: Use cacheable memory to store the rx buffer DMA address
Date: Fri, 17 Feb 2017 16:20:34 +0100	[thread overview]
Message-ID: <87fujcc08t.fsf@free-electrons.com> (raw)
In-Reply-To: <20170217145501.5b90a977@free-electrons.com> (Thomas Petazzoni's message of "Fri, 17 Feb 2017 14:55:01 +0100")

Hi Thomas,
 
 On ven., févr. 17 2017, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Does not make sense, because it's not the SW that refills the RX
> descriptors with the address of the RX buffers. It's done by the HW.
>
> With HWBM, I believe you have no choice but to read the physical
> address from the RX descriptor. But you can probably optimize things a
> little bit by reading it only once, and then storing it into a
> cacheable variable.
>
> So maybe:
>
>  - For SWBM, use the strategy proposed by Jisheng
>  - For HWBM, at the beginning of the RX completion path, read once the
>    rx_desc->buf_phys_addr, and store it in rxq->buf_dma_addr[index]


For the HWBM path storing rx_desc->buf_phys_addr in
rxq->buf_dma_addr[index] is not useful as we only use it in a single
function.

But a quick improvement could be to use the phys_addr variable. Indeed
we store the value of rx_desc->buf_phys_addr in it and we never used it,
instead we always use rx_desc->buf_phys_addr.

Gregory

>
> Of course that's just a very rough proposal. I've been looking mainly
> at mvpp2 lately, and I'm not sure I still remember how mvneta works in
> the details.
>
> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

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

  reply	other threads:[~2017-02-17 15:20 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 [this message]
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
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=87fujcc08t.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.