Re: iSCSI: frame formats

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

comments in text..

-Sandeep

Stephen Bailey wrote:
> 
> Sandeep,
> 
> > DataLen will now be max 8M/4M but then we dont wish to have large
> > iSCSI PDUs in any case.
> 
> This max size is getting the the point where I'm sure it'll be an
> irritant.

Your point about maxSize limitations set me thinking..

Hardware folks dont like parsing down the AHS to find the length 
field so perhaps putting jumbo-lengths in AHS is unattractive.

So what is the level of HW complexity in processing the SCSI PDUs which 
already have 6/10/12/16 byte commands, and consequently put the 
length field in *variable* locations ?   Can iSCSI adopt a similar
scheme to future-proof it from maxSize limitations ?

Roughly, a few extra states get added into the FSM to process variable 
length BHS based on the opcode, and you may need an extra register or
two.
But in hardware this can still get done in parallel.  Any thoughts ?

Needless to say, a SCSI-like variable BHS kills this 2-reads thingy that 
software implementors have been talking about.


> 
> I would like (but, in fact, a sure way to guarantee that it won't
> happen is for me to like it :^) to view iSCSI PDUs as the expected
> grain size at which you might have software involvement in an
> otherwise hardware-driven iSCSI implementation.
> 
> For example, when a target is returning read data for multiple
> outstanding reads, it might want to return a bit at a time from each,
> and each `bit' should be an iSCSI PDU.  Clearly sending these bits
> will be a software-level decision.  That certainly was the rational
> for allowing multiple FCP DATA PDUs per read operation, and I naively
> assumed similar logic was being applied here.
> 
> The alternative is to say that the hardware will do iSCSI PDU
> chunking, but if that's the case, I expect that the header is, well, a
> bit bulky.
> 
> I'm also incredibly unexcited about having data length be a multiple
> of 4 bytes (if that's still in the cards).  There operations within
> the SCSI command set which return arbitrary length data.  There are
> perfectly nominal cases where you get less data than you requested
> (e.g. inquiry & request sense).  Furthermore, the SCSI architecture
> does not prohibit this, even though certain commands do, so it is not
> for iSCSI to say anything about this one way or the other.


If I am not mistaken, dataLen value will be exact (not the padded)
and it will be in units of bytes (not words - this mistake was 
pointed out by someone at the IETF).


> 
> The problem with handling lengths that include padding comes when
> you're trying to move the data into a buffer which is a non-multiple
> length.  For example, if I ask for 22 bytes of inquiry data (with a 22
> byte buffer), what can I say, at the time a PDU arrives that has 24
> bytes?  It might have 21 or 22 bytes (or perhaps even, erroneously 23
> or 24 bytes).  A data residual coming later will tell the software how
> much was actually there, but it can't tell the hardware.  The typical
> expectation of this type of transfer is that it will only overwrite
> bytes of the buffer that are actually transferred, but having padded
> lengths will not allow this.
> 
> The completely standard solution to carrying arbitrary data of
> arbitrary length in an aligned transfer unit is to pad the transfer
> unit but report the exact (shorter) length.  Another solution, used by
> FC, is to carry a pad length.  In iSCSI, why bother---you've just
> reintroduced added the 2 bits you were trying to remove?
> 
> The data length scenario is not comparable to IP header lengths, where
> what is being carried is not arbitrary data.
> 
> Certainly, for iSCSI additional header segments (AHSs) you could
> arguably use this cell length technique, since we can control what
> we're carrying (AHSs that need exact byte lengths will have to be
> internally self-describing) but frankly, I still think it's a bad
> idea.
> 
> I can't understand why we're messing around with all these tricky
> `solutions' to standard problems.  We should avoid the temptation to
> get cute, and wholesomely provide the same capabilities as any other
> SCSI transport.  Specifically:
>   o allow long PDUs
>   o carry exact data lengths
> 
> Steph