On Mon, 2011-12-19 at 15:57 -0500, Matthew Wilcox wrote:
> On Mon, Dec 19, 2011 at 02:27:38PM -0600, James Bottomley wrote:
> > Hm, OK, that was actually something added to SAM-4. It's not present in
> > SAM-3. However, it does look like SAS always tried to get away with
> > this, notably by deciding in SAS-1 (which was SAM-3 based) that the
> > Frame tag wasn't the same thing as a SAM-3 Q.
>
> So ... T10 have put us in a bit of an awkward position here; by solving
> a problem that didn't need to be solved, they've created a new problem.
> We're sending a packet stream that's permitted by SAS-1 standards and not
> by SAS-2 standards (but probably isn't going to be checked by any device).
> To be technically correct, we've got to use shared tag maps (with the
> extra locking overhead) for any device that claims to be SAS-2 compliant.
> That's ... complex.
>
> So are we just going to pretend that T10 never made this change? :-)
No it's worse than that ... SAS-1 also had this language:
9.2.1
[...]
For COMMAND frames and TASK frames, the SSP initiator port shall
set the TAG field to a value that is unique for the I_T nexus
established by the connection (see 7.12). An SSP initiator port
shall not reuse the same tag when transmitting COMMAND frames or
TASK frames to different LUNs in the same SSP target port. An
SSP initiator port may reuse a tag when transmitting frames to
different SSP target ports. The TAG field in a COMMAND frame
contains the task tag defined in SAM-3. The TAG field in a TASK
frame does not correspond to a SAM-3 task tag, but corresponds
to an SAM-3 association (see 10.2.1). The tag space used in the
TAG fields is shared across COMMAND frames and TASK frames
(e.g., if a tag is used for a COMMAND frame, it is not also used
for a concurrent TASK frame).
Note the weasel language about the tag not being the SAM-3 tag but
containing it. I've no idea what a SAM-3 "association" is because a
word search on the SAM-3 spec doesn't find any such thing. It looks
like SAS always intended this and SAM-4 was modified to allow it.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
