All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Eric Dumazet
	<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Jianchao Wang
	<jianchao.w.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org,
	junxiao.bi-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating
Date: Sat, 13 Jan 2018 12:15:58 -0700	[thread overview]
Message-ID: <20180113191558.GC32353@ziepe.ca> (raw)
In-Reply-To: <e902138a-3508-3504-51e5-46152cc2fb31-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

On Fri, Jan 12, 2018 at 01:01:56PM -0800, Saeed Mahameed wrote:


> Simply putting a memory barrier on the top or the bottom of a functions,
> means nothing unless you are looking at the whole picture, of all the
> callers of that function to understand why is it there.

When I review code I want to see the memory barrier placed *directly*
before the write which allows the DMA.

So yes, this is my preference:

> update_doorbell() {
>     dma_wmb();
>     ring->db = prod;
> }

Conceptually what is happening here is very similar to what
smp_store_release() does for SMP cases. In most cases wmb should
always be strongly connected with a following write.

smp_store_release() is called 'release' because the write it
incorporates allows the other CPU to 'see' what is being
protected. Similarly here, the write to the db allows the device to
'see' the new ring data.

And this is bad idea:

> fill buffers();
> dma_wmb();
> update_doorbell();
 
> I simply like the 2nd one since with one look you can understand
> what this dma_wmb is protecting.

What do you think the wmb is protecting in the above? It isn't the fill.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@mellanox.com>
To: Saeed Mahameed <saeedm@mellanox.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Jianchao Wang <jianchao.w.wang@oracle.com>,
	tariqt@mellanox.com, junxiao.bi@oracle.com,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating
Date: Sat, 13 Jan 2018 12:15:58 -0700	[thread overview]
Message-ID: <20180113191558.GC32353@ziepe.ca> (raw)
In-Reply-To: <e902138a-3508-3504-51e5-46152cc2fb31@mellanox.com>

On Fri, Jan 12, 2018 at 01:01:56PM -0800, Saeed Mahameed wrote:


> Simply putting a memory barrier on the top or the bottom of a functions,
> means nothing unless you are looking at the whole picture, of all the
> callers of that function to understand why is it there.

When I review code I want to see the memory barrier placed *directly*
before the write which allows the DMA.

So yes, this is my preference:

> update_doorbell() {
>     dma_wmb();
>     ring->db = prod;
> }

Conceptually what is happening here is very similar to what
smp_store_release() does for SMP cases. In most cases wmb should
always be strongly connected with a following write.

smp_store_release() is called 'release' because the write it
incorporates allows the other CPU to 'see' what is being
protected. Similarly here, the write to the db allows the device to
'see' the new ring data.

And this is bad idea:

> fill buffers();
> dma_wmb();
> update_doorbell();
 
> I simply like the 2nd one since with one look you can understand
> what this dma_wmb is protecting.

What do you think the wmb is protecting in the above? It isn't the fill.

Jason

  parent reply	other threads:[~2018-01-13 19:15 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12  3:42 [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating Jianchao Wang
2018-01-12  3:42 ` Jianchao Wang
2018-01-12 16:32 ` Jason Gunthorpe
     [not found]   ` <20180112163247.GB15974-uk2M96/98Pc@public.gmane.org>
2018-01-12 16:46     ` Eric Dumazet
2018-01-12 16:46       ` Eric Dumazet
2018-01-12 19:53       ` Saeed Mahameed
     [not found]         ` <85116e56-52b1-944d-6ee2-916ccfc3a7a6-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2018-01-12 20:16           ` Eric Dumazet
2018-01-12 20:16             ` Eric Dumazet
2018-01-12 21:01             ` Saeed Mahameed
2018-01-12 21:21               ` Eric Dumazet
     [not found]               ` <e902138a-3508-3504-51e5-46152cc2fb31-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2018-01-13 19:15                 ` Jason Gunthorpe [this message]
2018-01-13 19:15                   ` Jason Gunthorpe
2018-01-14  2:40       ` jianchao.wang
     [not found]         ` <a40e44f4-106b-1075-8f92-f7741508372c-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-14  9:47           ` Tariq Toukan
2018-01-14  9:47             ` Tariq Toukan
2018-01-15  5:50             ` jianchao.wang
     [not found]               ` <fea0aa1c-b68e-9485-3826-2dfad7824911-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-19 15:16                 ` jianchao.wang
2018-01-19 15:16                   ` jianchao.wang
     [not found]                   ` <53b1ac4d-a294-eb98-149e-65d7954243da-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-19 15:49                     ` Eric Dumazet
2018-01-19 15:49                       ` Eric Dumazet
2018-01-21  9:31                       ` Tariq Toukan
     [not found]                         ` <dfc02a48-7d2a-56da-dc4e-d90a9fcc559c-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2018-01-21 16:24                           ` Tariq Toukan
2018-01-21 16:24                             ` Tariq Toukan
2018-01-21 16:43                             ` Eric Dumazet
     [not found]                               ` <1516552998.3478.5.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-22  2:40                                 ` jianchao.wang
2018-01-22  2:40                                   ` jianchao.wang
2018-01-22 15:47                                   ` Jason Gunthorpe
2018-01-23  3:25                                     ` jianchao.wang
2018-01-22  2:12                             ` jianchao.wang
     [not found]                               ` <c8b0955b-a3fc-afe2-2c67-e655ca2ee6f6-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-25  3:27                                 ` jianchao.wang
2018-01-25  3:27                                   ` jianchao.wang
     [not found]                                   ` <532b4d71-e2eb-35f3-894e-1c3288e7bc3f-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-25  3:55                                     ` Eric Dumazet
2018-01-25  3:55                                       ` Eric Dumazet
     [not found]                                       ` <1516852543.3715.43.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-25  6:25                                         ` jianchao.wang
2018-01-25  6:25                                           ` jianchao.wang
     [not found]                                           ` <89066a75-43db-0f62-f171-70b0abaa8ea0-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2018-01-25  9:54                                             ` Tariq Toukan
2018-01-25  9:54                                               ` Tariq Toukan
     [not found]                                               ` <918db4ec-8c3c-aafa-4be6-0e00a99632e2-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2018-01-27 12:41                                                 ` jianchao.wang
2018-01-27 12:41                                                   ` jianchao.wang
     [not found]                                                   ` <d9883261-e93e-400a-757c-3a81d8b6aca1@mellanox.com>
2019-01-02  1:43                                                     ` jianchao.wang
2018-01-21 20:40                         ` Jason Gunthorpe

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=20180113191558.GC32353@ziepe.ca \
    --to=jgg-vpraknaxozvwk0htik3j/w@public.gmane.org \
    --cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jianchao.w.wang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=junxiao.bi-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org \
    --cc=tariqt-VPRAkNaXOzVWk0Htik3J/w@public.gmane.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.