[Stgt-devel] target parser problems with SAS

[Douglas Gilbert]

I'm looking at adding a SAS target to tgt. There is
already an in-kernel ramdisk type driver which works
on my LSI MPT Fusion hardware. Hence I suspect it can
be done. Unfortunately a big hammer may be required
on the existing tgt user space code.

It looks like SAS may be different from other SCSI
transports in that the target "pulls" data_out bytes
from the initiator. This means that for commands like
WRITE (SBC) and MODE SELECT the parser first receives
the cdb only. The parser then needs to determine the
byte count to be fetched and send that number back to
the transport. The parser will then get entered a second
time for the same cdb, this time with data attached.

In the case of SBC the byte count is not obvious to
the target code (in kernel). It is the lu context
(in user space) that knows the block size. Further
that block size may have been recently changed with
a FORMAT command.

For those interested in the low level details see the
SAS XFER_RDY frame in its transport layer. Even though
MPT Fusion firmware hides this level of detail, the
requirement remain to calculate the length of data to
"pull" on a WRITE like command. This "feature" might
explain why SAS disks have better queued write
performance than its FC and SPI cousins.


So, do folks want the various tgt parsers changed to
cope with SAS ??

Doug Gilbert