RE: Command Queue Depth (was asymmetric/Symmetric)

[Jim McGrath <Jim.McGrath@quantum.com>]

Peter,

In SBP-2 the target initiates things like getting commands and data from the
host (where they are stored).  So the target does a number of things with
respect to the initiator to discover if command/data exist for it and then
get the command/data for processing.  Then the initiator (at target request)
has to send this information to the target.

In the extreme the target would only has to accept out of the blue an alert
message (just a bit of information) from each initiator, telling it that the
initiator has something for it (the alternative is target polling of all the
initiators, not attractive in this environment).  The problem now is that
you have to generate target to initiator traffic (with its own latency)
before you even get to knowing the commands and data in the initiator space.

Afterall, the desire to send out of the blue commands and data is there for
two reasons:
     it allows the target to start working as fast as possible,
     it minimizes bus traffic by minimizing request/response transactions.

You could say that a target initiated request for command/data information
could occur just before the target became free (or at least target resources
became free) from previous operations, allowing the target to always keep
itself fed with tasks, but not overfed.  That might work, although the
timing is difficult due to the variance in the response times.

But it would not address any bus utilization issues (and indeed, probably
make them worse).  It also adds some initial latency in lightly loaded
systems since the simple initiator sending a command to a target is replaced
by sending an alert and then having the target get a command.

So yes, I think the SBP-2 style of target initiated actions might make some
sense in heavily loaded systems, which a more traditional approach is
appropriate for lightly loaded situations.  The trick is having the
distributed targets and initiators figuring out when to use each one
(difficult) or focusing on one (as we have traditionally) and basically
optimizing latency for light or heavy loads, but not both.

Jim





-----Original Message-----
From: Peter Johansson [mailto:PJohansson@ACM.org]
Sent: Sunday, September 10, 2000 4:38 AM
To: IP Storage
Subject: RE: Command Queue Depth (was asymmetric/Symmetric)


At 08:06 PM 9/6/00, Jim McGrath wrote:

>The issue of buffer space allocation for multiple initiators has a long 
>and troubled history in SCSI.  We have never been able to come up with a 
>good answer.
>
>Note: the same problem has plagued other attempts to allocate device 
>resources between multiple initiators, like command queue space.  In 
>general policies with respect to multiple initiators are not really 
>standard in the SCSI world.

Jim's response is correct as far as it goes, but it ignores the solution 
adopted in SBP-2, which neatly finesses these issues by leaving the 
resources in the initiator.

In fairness, it's likely that the appropriateness (or lack thereof) of an 
iSCSI solution similar to SBP-2 has been ignored in these discussions 
because SBP-2 has been less widely implemented than parallel SCSI or FCP.

Is it possible that the SBP-2 approach is relevant to iSCSI? That is, put 
the initiator in the role of "memory server" and let the target manage when 
and how its own resources are used to effect the transfer of data. This 
might make sense if the model places more of the assumed resources 
(principally memory) in the initiator.

Can this be effected efficiently?




Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

PJohansson@ACM.org