All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Huazhong Tan <tanhuazhong@huawei.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <salil.mehta@huawei.com>,
	<yisen.zhuang@huawei.com>, <linuxarm@huawei.com>,
	Yunsheng Lin <linyunsheng@huawei.com>
Subject: Re: [PATCH net-next 5/6] net: hns3: use writel() to optimize the barrier operation
Date: Mon, 14 Sep 2020 14:45:22 -0700	[thread overview]
Message-ID: <20200914144522.02d469a8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <1600085217-26245-6-git-send-email-tanhuazhong@huawei.com>

On Mon, 14 Sep 2020 20:06:56 +0800 Huazhong Tan wrote:
> From: Yunsheng Lin <linyunsheng@huawei.com>
> 
> writel() can be used to order I/O vs memory by default when
> writing portable drivers. Use writel() to replace wmb() +
> writel_relaxed(), and writel() is dma_wmb() + writel_relaxed()
> for ARM64, so there is an optimization here because dma_wmb()
> is a lighter barrier than wmb().

Cool, although lots of drivers will need a change like this now. 

And looks like memory-barriers.txt is slightly, eh, not coherent there,
between the documentation of writeX() and dma_wmb() :S

	3. A writeX() by a CPU thread to the peripheral will first wait for the
	   completion of all prior writes to memory either issued by, or
	   propagated to, the same thread. This ensures that writes by the CPU
	   to an outbound DMA buffer allocated by dma_alloc_coherent() will be
	   visible to a DMA engine when the CPU writes to its MMIO control
	   register to trigger the transfer.



 (*) dma_wmb();
 (*) dma_rmb();

     These are for use with consistent memory to guarantee the ordering
     of writes or reads of shared memory accessible to both the CPU and a
     DMA capable device.

     For example, consider a device driver that shares memory with a device
     and uses a descriptor status value to indicate if the descriptor belongs
     to the device or the CPU, and a doorbell to notify it when new
     descriptors are available:

	if (desc->status != DEVICE_OWN) {
		/* do not read data until we own descriptor */
		dma_rmb();

		/* read/modify data */
		read_data = desc->data;
		desc->data = write_data;

		/* flush modifications before status update */
		dma_wmb();

		/* assign ownership */
		desc->status = DEVICE_OWN;

		/* notify device of new descriptors */
		writel(DESC_NOTIFY, doorbell);
	}

     The dma_rmb() allows us guarantee the device has released ownership
     before we read the data from the descriptor, and the dma_wmb() allows
     us to guarantee the data is written to the descriptor before the device
     can see it now has ownership.  Note that, when using writel(), a prior
     wmb() is not needed to guarantee that the cache coherent memory writes
     have completed before writing to the MMIO region.  The cheaper
     writel_relaxed() does not provide this guarantee and must not be used
     here.

  reply	other threads:[~2020-09-14 21:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 12:06 [PATCH net-next 0/6] net: hns3: updates for -next Huazhong Tan
2020-09-14 12:06 ` [PATCH net-next 1/6] net: hns3: batch the page reference count updates Huazhong Tan
2020-09-14 12:06 ` [PATCH net-next 2/6] net: hns3: batch tx doorbell operation Huazhong Tan
2020-09-14 12:06 ` [PATCH net-next 3/6] net: hns3: optimize the tx clean process Huazhong Tan
2020-09-14 12:06 ` [PATCH net-next 4/6] net: hns3: optimize the rx " Huazhong Tan
2020-09-14 12:06 ` [PATCH net-next 5/6] net: hns3: use writel() to optimize the barrier operation Huazhong Tan
2020-09-14 21:45   ` Jakub Kicinski [this message]
2020-09-15  1:41     ` Yunsheng Lin
2020-09-14 12:06 ` [PATCH net-next 6/6] net: hns3: use napi_consume_skb() when cleaning tx desc Huazhong Tan
2020-09-15  5:09   ` Saeed Mahameed
2020-09-15  7:04     ` Yunsheng Lin
2020-09-16  8:33       ` Saeed Mahameed
2020-09-16  8:38         ` Eric Dumazet
2020-09-17  6:52           ` Yunsheng Lin

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=20200914144522.02d469a8@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=linyunsheng@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=salil.mehta@huawei.com \
    --cc=tanhuazhong@huawei.com \
    --cc=yisen.zhuang@huawei.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 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.