Should SIP require detection of duplicate tags?

Rod Dekoning rdekonin at
Mon Apr 18 09:24:45 PDT 1994

>> How bit is enormous?  SIP can have 15 initiators and up to 256 tags per 
>> initiator, for a total of 65,280 possible tags.  Is this enormous enough?

>I think your math is in error.  15 * 256 = 3840.   :-)

>I agree with your analysis of the issue.  I did much of the work on
>the queuing firmware for HP.  We only found that the overlapped tags
>occurred during the debug of driver code.  I have been one who has
>fought against checking of the tags once serial interfaces were 

>In regards to the SIP implementations, I think that the tag checking
>can be optional here also.  The checking really doesn't add to an
>implementation.  If a target disconnects from an initiator, then I
>think there is time in f/w to do the checking.  If the target is 
>automated in the data transfers and will send the data without a 
>disconnect, then the tag checking is totally useless since the
>nexus information cannot be confused.  

>I guess what I am saying is that I would not expect h/w to do tag 
>checking.  I'm guessing that's the "right" answer, Steve.

Systems with 32 logical units provides the maximum number of queued commands in 
the range that Steve was eluding to (I get 15 * 256 * 32 Logical Units = 

I am concerned about the perception that all targets have a ample time to check 
duplicate tags.  One of the concepts behind queuing is to allow the target 
opportunities to maximize its bandwidth/throughput through various optimizations
including seek sorting, concatenation of IO requests, etc.  In systems with 
large numbers of LUNs, these algorithms (plus many more that are application 
specific) lead to maximum utilization of the cpu resource.  As such, the time to
check for duplicate tags becomes excessive.  (- even if only a few 

The checking of duplicate tags provides no real value add, and should not be 

Rod DeKoning

More information about the T10 mailing list