From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagi Grimberg Subject: Re: [PATCH] net/mlx5: fix Tx doorbell memory barrier Date: Sun, 22 Oct 2017 12:46:53 +0300 Message-ID: References: <20171022080022.13528-1-yskoh@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, stable@dpdk.org, Alexander Solganik To: Yongseok Koh , adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com Return-path: In-Reply-To: <20171022080022.13528-1-yskoh@mellanox.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > Configuring UAR as IO-mapped makes maximum throughput decline by noticeable > amount. If UAR is configured as write-combining register, a write memory > barrier is needed on ringing a doorbell. rte_wmb() is mostly effective when > the size of a burst is comparatively small. Personally I don't think that the flag is really a good interface choice. But also I'm not convinced that its dependent on the burst size. What guarantees that even for larger bursts the mmio write was flushed? it comes after a set of writes that were flushed prior to the db update and its not guaranteed that the application will immediately have more data to trigger this writes to flush.