Subject: RE: new iSCSI PDU outline

From: [email-masked]
Date: Fri, 26 Jan 2001 18:29:15 +0200

Doug,

You are right and we could do it but it will reduce the number of yet
unallocated types in WN (and T10 is adding more stuff to the SCSI!) and
will save us several bits in the command where we have plenty. I don't
think it is worth it.

Regards,
Julo

"Douglas Otis" <[email-masked]> on 26/01/2001 00:41:02

Please respond to "Douglas Otis" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: new iSCSI PDU outline

Julian,

Would you consider splitting headers.  As was done with MTF, there was just
a simple 32 bit simple XOR checksum for header fields.  Here is an example
with a CDB appended.  The WN could expand the appended type into SCSI_CMND,
SCSI_RSP, SCSI_R2T, iSCSI_Specific, etc.

  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  +---------------+---------------+---------------+---------------+
 0| WN            | Reserved                      | AddCDB        |
  +---------------+---------------+---------------+---------------+
 4| Length                                                        |
  +---------------+---------------+---------------+---------------+
 8| ->CmdSN or <-StatRN                                           |
  +---------------+---------------+---------------+---------------+
12| ->ExpStatSN or <-ExpCmdSN                                     |
  +---------------+---------------+---------------+---------------+
16| ->MaxStatRN? <-MaxCmdSN                                       |
  +---------------+---------------+---------------+---------------+
20| XOR Checksum                                                  |
  +---------------+---------------+---------------+---------------+
  +---------------+---------------+---------------+---------------+
24| SCSI_CMND  ...                                                |
  +-                                                              |
32|                                                               |
  +---------------+---------------+---------------+---------------+
36| CDB ...                                                          |
  +---------------+---------------+---------------+---------------+
x | (Data ...)                                                         |
  +---------------+---------------+---------------+---------------+
y | CRC                                                           |
  +---------------+---------------+---------------+---------------+

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 26 Jan 2001 11:23:04 -0800

Julian,

Should there be software implementations that must deal with iSCSI on a
real-time basis, splitting the headers as I described helps in allowing the
transport to respond immediately in providing the transport related
feed-back.  The split header and simple XOR calculation was to make this
possible with software implementations where these settings are made
nano-seconds before being sent.  To require a CRC to be done could introduce
many micro-seconds into the operation and thus make the transport less
current on its feed-back as this must be pipelined.  You have a few other
fields not defined and perhaps use those fields to expand the later content.
I doubt there will be more than a handful of types but if you use 16 bits,
there should never be a danger of running out of options.  In addition, I
would suggest retry flags be placed in this header for the same reasons of
simplifying the transport.  Once the SCSI structure is created, it becomes
independent of the transport functions so that fiddling at the transport
will not spoil this content.  By keeping these values to but a few fields
unrelated to the payload, a simple check should be all that is needed.

Doug