Re: Read data chunk size and segmentation negotiation

[Stephen Bailey <steph@cs.uchicago.edu>]

Mark Burton,

> I understand from your response that it is an (implicit) requirement
> that all initiators must always accept a data response of any length
> up to the expected data transfer length.

This behavior parallels FCP.  The target can control the flow of write
data to it, but the initiator can not do the same for read data.
Furthermore, an FCP target can send read data in as many `bursts' as
it choses, but an FCP initiator can only send a single burst in
response to an XFR_RDY.

> I just wonder if there is (or will be) any situation that would
> require the size of the data responses to be limited by the initiator
> whilst still allowing for a larger data transfer length. If no such
> situation can ever occur then the negotiation is not required.

Personally, I've always found the FCP behavior a bit cramping.  Then
again, some people would with the claim that either my approach, or
what I am trying to do is stupid :^) 

This behavior has a basis in the SAM, where it says something about
assuming that all the buffer resources are are allocated before a SCSI
task is initiated.

A similar argument of the form `initiators are resource rich where
targets are not (for cost reasons)', is also frequently made.  By not
allowing initiator flow control, a target can discharge a single
operation at a time and still be efficient.  In other words, it can
count on returning the data for one read in its entirety before moving
on to the next read.  That means that the target only needs buffering
for a small, constant number of operations, c, rather than cI (where I
is # of initiators).

iSCSI targets are going to have to be more sophisticated than FCP
targets because of the assumption that transfers are likely, rather
than rarely rate-limited.  However, if the initiator is allowed
arbitrary flow control, the target's buffering requirements go from cI
to cO, where O is the total number of outstanding operations (from all
initiators).  I'm not clear whether this is a big deal, or noise.  It
seems like once you've made the jump from c to cI, cO isn't going to
be much worse.  RAID boxes already have cI or cO level buffering, it's
only drives where there's any question.

Steph