[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56545D98.1020904@talpey.com>
Date: Tue, 24 Nov 2015 07:52:40 -0500
From: Tom Talpey <tom@...pey.com>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Caitlin Bestler <cait@...mi.com>
Cc: Bart Van Assche <bart.vanassche@...disk.com>,
Christoph Hellwig <hch@....de>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"sagig@....mellanox.co.il" <sagig@....mellanox.co.il>,
"axboe@...com" <axboe@...com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/9] IB: add a proper completion queue abstraction
On 11/24/2015 2:03 AM, Jason Gunthorpe wrote:
> On Mon, Nov 23, 2015 at 06:35:28PM -0800, Caitlin Bestler wrote:
>> Are there actual HCAs that make this mistake?
>
> All IB HCAs have this behavior and require apps to see a send CQ
> completion before making any statements about the state of the send Q
> or buffers handed over to the HCA. Tom and I have seen this in real
> systems under proper stress conditions. [Which is why I am so certain
> about this, because when I first hit it years ago I dug into the spec
> and figured out it was not a HW bug I was looking at]
To be clear, I saw the reply-completion-before-request-completion on
Windows, not Linux, but the principle is identical. It's simply a
fact of life on a multiprocessor, unless you want to throw in locks
and synchronization rules that drivers have to follow to enforce
ordered completions across queues. Which trust me, you don't.
In Windows SMB Direct, we added reference counts around pretty much
every verb interaction associated with each upper layer operation,
and did not retire them until all refcounts went to zero. It is
excruciatingly correct yet performs incredibly well.
Tom.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists