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
next prev 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: linkBe 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.