RE: iSCSI: frame formats

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

Stephen,

	I don't agree with your concerns about the maximum PDU
size. I think few targets, or indeed initiators, will be
interested in negotiating PDU sizes anywhere near this
large, so big transfers will have to be fragmented anyway.

	However, I share your concern about the padding. I don't
really see why we are considering it. If one has a local
alignment issue it can, and I believe should, be taken care
of locally and not in the specification. There are several
easy ways of handling this sort of thing; insert and remove
the pad locally; separate header and payload buffers
allowing each to be naturally aligned, etc.

	If we have to pad then every read of non-header data will
have to involve a rounding calculation on the length, and
then perhaps a second read to discard the pad if the
underlying buffer is the exact size of the data. Possibly
the same on send, if the data buffer is the exact size the
transmit code can't just 'go off the end,' it will have to
send the data, and then fake up some pad and make another
send.

	Am I missing something here, why do we care about padding?

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
Behalf Of
Stephen Bailey
Sent: Monday, April 02, 2001 3:18 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: frame formats


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.

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.

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