iSCSI: LUN field in PDUs

["Rod Harrison" <rod.harrison@windriver.com>]

	Carrying the LUN in some of the iSCSI messages can be a
little awkward for the initiator since it has to find the
LUN. This means the initiator has to understand the CDB and
know whether we are in the SCSI 1/2 3 bit LUN or a more
modern world. I understand the argument that some targets
might want to steer based on the LUN but I also think Matt
Wakeley has a valid point when he says the target should be
able to steer based on the target task tag alone. I have a
proposal that might get us the best of both worlds.

	I believe in practice most targets will want to use
solicited data mode, perhaps with a fairly small amount of
immediate data [reasoning at the end of this message to
avoid cluttering things]. This being so, I think we could
get away with leaving all the messages as they are except
the SCSI command PDU. Let's take the LUN field out of there
(make it reserved), since the LUN is in the CDB anyway. This
would avoid the initiator having to grub around inside a
protocol layer's data it might not want to understand. If
the target wants to be a 'pure tunnel' and not crack open
the CDB it can do so, and if the target wants to steer on
the LUN it still has that information at the cost of
understanding the CDB. This doesn't seem to bad from the
target point of view.

	If the target wants to steer on the LUN we can have it
include the LUN in the R2T, and perhaps a flag bit to say
this has happened. The initiator should always return the
LUN in subsequent messages if the target has included it in
the R2T.

	The overall effect of this change would be relatively
minor. Command PDU has a simple change, data PDUs remain the
same. I'm not sure why we are carrying LUN in the NOPs since
they are iSCSI protocol management messages and are not
really related to any underlying SCSI device. I assume the
LUN in NOP-OUT is there to carry whatever the target might
set in the LUN field of NOP-IN. If this is so then we need
no changes to NOPs.

	My main sticking point with this is the task management
PDU. The initiator might want to send a task management PDU
before the target has responded with an R2T. Indeed, there
might never be an R2T if the initial burst satisfies the
entire data transfer. Do we really need the LUN in task
management PDUs? No matter where the target thinks it should
steer the PDU based on the LUN it still has to go find the
task associated with the initiator task tag.

	- Rod Harrison

[Target use of R2T reasoning]

	The reason I believe most targets will prefer solicited
data is simply one of buffer management. If the target is
controlling many SCSI devices, and thus running many iSCSI
sessions to many initiators I think the only viable way to
control buffer usage is via R2T. Since the target can never
know how many sessions it might have to manage, and how many
commands will be outstanding in each session it would have
to be very conservative in negotiations for the amount of
unsolicited data. If some sessions are much more active than
others, this could lead to the active sessions being
throttled because of negotiated limits whilst only a small
amount of buffers are being used on the target overall. The
tighter feedback loop afforded by R2T would seem to be the
way to go.