lkml.org 
[lkml]   [2010]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
Hannes Reinecke, on 08/30/2010 01:54 PM wrote:
>> As I've wrote multiple times, I'm pretty skeptical it will bring much.
>> Ordered tag mandates draining inside the device just like the original
>> barrier implementation. Sure, it's done at a lower layer and command
>> issue latencies will be reduced thanks to that but ordered-by-waiting
>> doesn't require _any_ draining at all. The whole pipeline can be kept
>> full all the time. I'm often wrong tho, so please feel free to go
>> ahead and prove me wrong. :-)
>>
> Actually, I thought about ordered tag writes, too.
> But eventually I had to give up on this for a simple reason:
> Ordered tag controls the ordering on the SCSI _TARGET_. But for a
> meaningful implementation we need to control the ordering all the way
> down from ->queuecommand(). Which means we have three areas we need
> to cover here:
> - driver (ie between ->queuecommand() and passing it off to the firmware)
> - firmware
> - fabric
>
> Sadly, the latter two are really hard to influence. And, what's more,
> with the new/modern CNAs with multiple queues and possible multiple
> routes to the target it becomes impossible to guarantee ordering.
> So using ordered tags for FibreChannel is not going to work, which
> makes implementing it a bit of a pointless exercise for me.

The situation is, actually, much better than you think. An SCSI
transport should provide an in-order delivery of commands. In some
transports it is required (e.g. iSCSI), in some - optional (e.g. FC).
For FC "an application client may determine if a device server supports
the precise delivery function by using the MODE SENSE and MODE SELECT
commands to examine and set the enable precise delivery checking (EPDC)
bit in the Fibre Channel Logical Unit Control page" (Fibre Channel
Protocol for SCSI (FCP)). You can find more details in FCP section
"Precise delivery of SCSI commands".

Regarding multiple queues, in case of a multipath access to a device
SCSI requires either each path be a separate I_T nexus, where order of
commands is maintained, or a transport required to maintain in-order
commands delivery among multiple paths in a single I_T nexus (session)
as it is done in iSCSI's MC/S and, most likely, wide SAS ports.

So, everything is in the specs. We only need to use it properly. How it
can be done on the drivers level as well as how errors recovery can be
done using ACA and UA_INTLCK facilities I wrote few weeks ago in the
"[RFC] relaxed barrier semantics" thread.

Vlad


\
 
 \ /
  Last update: 2010-08-30 22:39    [W:0.214 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site