From: Casey Leedom <leedom@chelsio.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: Vipul Pandya <vipul@chelsio.com>,
Steve Wise <swise@opengridcomputing.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-scsi@vger.kernel.org, roland@purestorage.com,
JBottomley@parallels.com, Dimitrios Michailidis <dm@chelsio.com>,
Naresh Kumar Inna <naresh@chelsio.com>,
Divy Le Ray <divy@chelsio.com>,
Santosh Rastapur <santosh@chelsio.com>,
Arvind Bhushan <arvindb@chelsio.com>,
Abhishek Agrawal <abhishek@chelsio.com>
Subject: Re: [PATCH net-next 05/22] cxgb4: Add T5 write combining support
Date: Wed, 13 Mar 2013 15:54:45 -0700 [thread overview]
Message-ID: <514103B5.7040002@chelsio.com> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B718B@saturn3.aculab.com>
On 03/13/13 08:43, David Laight wrote:
> From my recollection of the x86 architecture, the memory barriers are
> hardly ever needed, certainly not in the places where, for example a
> ppc needs them. I'd actually suspect that the normal wmb() for x86
> should be a nop. About the only place where any on the fence
> instructions are needed are in relation to write combining accesses.
> In particular I don't believe they are ever needed to synchronise
> uncached accesses with each other, or with cached accesses (which are
> snooped). David
The question at hand is how should we indicate that we're finished
with a Write Combined set of stores in an architecturally neutral
manner? Is wmb() a good approach? Vipul has noted that the iWarp code
uses a new "wc_wmb()" for this purpose which seems to be the same
_currently_ as wmb() for all current platforms. I presume that the
iWarp folks pick a new name to offer themselves some cover in the future.
And yes, the code sequence that was accidentally included in Vipul's
previous patches should never have been submitted for inclusion in
kernel.org. It got missed in our internal reviews and I apologize for that.
Casey
next prev parent reply other threads:[~2013-03-13 22:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 11:46 [PATCH net-next 00/22] Add support for Chelsio T5 adapter Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 01/22] cxgb4: Add register definations for T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 02/22] cxgb4: Add macros, structures and inline functions " Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 03/22] cxgb4: Initialize T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 06/22] cxgb4: Enable doorbell drop recovery only for T4 adapter Vipul Pandya
[not found] ` <1363088794-31453-1-git-send-email-vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
2013-03-12 11:46 ` [PATCH net-next 04/22] cxgb4: Dump T5 registers Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 05/22] cxgb4: Add T5 write combining support Vipul Pandya
2013-03-12 12:19 ` David Miller
[not found] ` <20130312.081927.1036246728528667686.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2013-03-12 14:42 ` Steve Wise
[not found] ` <513F3EBD.5020504-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2013-03-13 14:36 ` Vipul Pandya
2013-03-13 15:43 ` David Laight
2013-03-13 22:54 ` Casey Leedom [this message]
2013-03-12 11:46 ` [PATCH net-next 07/22] cxgb4: Add T5 debugfs support Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 08/22] cxgb4: Add T5 PCI ids Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 09/22] cxgb4: Update driver version and description Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 10/22] cxgb4: Disable SR-IOV support for PF4-7 for T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 11/22] cxgb4vf: Add support for Chelsio T5 adapter Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 12/22] RDMA/cxgb4: Add Support " Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 13/22] RDMA/cxgb4: Turn off db coalescing when RDMA QPs are in use Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 14/22] RDMA/cxgb4: Add module_params to enable DB FC & Coalescing on T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 15/22] RDMA/cxgb4: Use DSGLs for fastreg and adapter memory writes for T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 16/22] RDMA/cxgb4: Map pbl buffers for dma if using DSGL Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 17/22] RDMA/cxgb4: Bump tcam_full stat and WR reply timeout Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 18/22] RDMA/cxgb4: Fix onchip queue support for T5 Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 19/22] csiostor: Segregate T4 adapter operations Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 20/22] csiostor: Add T5 " Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 21/22] csiostor: Header file modifications for chip support and bug fixes Vipul Pandya
2013-03-12 11:46 ` [PATCH net-next 22/22] csiostor: Cleanup chip specific operations Vipul Pandya
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=514103B5.7040002@chelsio.com \
--to=leedom@chelsio.com \
--cc=David.Laight@ACULAB.COM \
--cc=JBottomley@parallels.com \
--cc=abhishek@chelsio.com \
--cc=arvindb@chelsio.com \
--cc=davem@davemloft.net \
--cc=divy@chelsio.com \
--cc=dm@chelsio.com \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=naresh@chelsio.com \
--cc=netdev@vger.kernel.org \
--cc=roland@purestorage.com \
--cc=santosh@chelsio.com \
--cc=swise@opengridcomputing.com \
--cc=vipul@chelsio.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).