QErr, Basic Queuing and SBP-2

PJohansson at aol.com PJohansson at aol.com
Thu Feb 20 20:18:58 PST 1997


* From the SCSI Reflector (scsi at symbios.com), posted by:
* PJohansson at aol.com
*
Jim, I don't think you have captured my thinking correctly. See below:

In a message dated 97-02-20 21:35:20 EST, jmcgrath at qntm.com (Jim Mcgrath)
writes:

<<The problem Peter is what should a Basic queuing device do if put into a
multiple initiator setting.  According to Charles, it should operate proprly
(i.e. clear commands for only the affected initiators).  In that case, the
firmware must be written and tested to support it, and so Basic queuing is
gutted.>>

I believe there are two varieties of Basic queing devices: a) those designed
for a single initiator and b) those designed for multiple initiators. A
single initiator Basic queuing device should refuse requests from more than
one initiator AT A TIME. This requires none of the additional firmware to
which you refer; by no stretch of the imagination is "...Basic
queuing...gutted."
      
<<I think you are saying that a Basic queuing device simply should not be
used in a multiple initiator setting.  I would feel fine with that it the
Standard said loud clear that a Basic queuing device in a multiple initiator
setting behaves in a vendor unique manner.  But that is not what Charles
wants.>>

This is not what I am saying, at all. My recollection is that you first
sought the proposed Basic queuing for simple, single-initiator devices. If my
recollection is inaccurate, I accept your correction----but this doesn't
affect my opinion of what Basic queuing should be. I don't think that T10
should standardize an architecture that is broken. I believe that QErr == 01b
is broken in the multiple initiator environment. The SBP-2 working group
discussed this in Redmond and likewise does not wish to establish an
architecture with demonstrable flaws when multiple initiators are present. A
"...vendor unique..." solution for a Basic queuing device in a multiple
initiator setting is not OK.
      
<<I do not want to reject commands from other initiators - I accept them
today fine, and work well in most applications. I simply do not want to
handle every corner case - that is what full queuing is all about.>>

I believe that there is still substantial code simplification from the Full
queuing model to the Basic model, whether or not you choose single or
multiple initiator support. If you choose single initiator support, only, you
of course have 100% of the simplification you would like. If you need to sell
into a multiple initiator arena, I can't see how it is in your long-term
interests to advocate a vendor unique, non-uniform solution.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

pjohansson at aol.com

PS I don't think you should personalize so much of this as Charles' opinion;
I believe many others support the proposals in 96-277r1.


*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list