Subject: Re: iSCSI: frame formats

From: [email-masked]
Date: Tue, 10 Apr 2001 07:08:43 +0200

Steph,

Read10 and Write10 can still be accomodated with several data PDUs as we
maintained the total read/write count (expected data) as a 32 bit field.
It is only the individual PDU that went down to 16M.

It is worth noticing also that the CRCs we are contemplating have a
guaranteed haming distance of 4 for blocklengths of less than 2^31 bits.

Julo

Stephen Bailey <[email-masked]> on 09/04/2001 18:24:09

Please respond to Stephen Bailey <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI: frame formats

> No one felt that a max data size of 16 megs in an iSCSI PDU was an
> issue

I did, I was just exhausted.  Furthermore, the size the PDU could
handle shrank (from 64M to 16M) right there before our ears in a split
second.

The `question' was also not asked in a form which I could effectively
answer or discuss.  There were two proposals presented, and they had
very different characteristics.  I figured I would refrain from
comment until I a) understood the proposals better b) got a sense of
which way we might be going.

I have a hard time swallowing a PDU that won't accomodate the data
from even a READ10 or WRITE10.

If people expect to tile each TCP segment with an iSCSI PDU, I think
that's a mistake.  The headers are too bulky for that.  If they think
they're going to gain something meaningful in hardware implementation
complexity (e.g. bounding the amount of reassembly buffering) by
assuming small multiples of segment size PDUs, I think that's a
mistake too.  I'd like to see a show of hands of people who have
actually implemented this approach in hardware.  Anybody?

If you (eventually) accept this, then you're back to the model that
there's a lower layer which is providing your data steering on a
per-segment basis, and your iSCSI PDU is the granularity at which the
iSCSI implementation delivers data to this layer.  It is clearly a
granularity at which software (transfer scheduling) occurs.

At 10 Gbit/s, a 16 MB PDU is only 16 MS worth of data.

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 11 Apr 2001 10:35:56 -0400

Julian,

> It is only the individual PDU that went down to 16M.

I realize that.  I said that Read10 could not be accommodated within a
SINGLE PDU.

I know the endpoints CAN tile the data into sequences of PDUs of
arbitrarily small size.  The question is whether they WANT to do that.
My endpoints don't.  It boils down to whether you want to tile iSCSI
PDUs in hardware or not.  If you use something like an RDMA layer to
do your data handling, it's better not to add an additional ULP tiling
requirement.  You want to have the protocol support arbitrarily large
(within some expansive limit like 2^32) PDUs.

> guaranteed haming distance of 4 for blocklengths of less than 2^31 bits.

Understood.  Yet another reason to insert integrity below iSCSI.
Disabling CRC is presently supported, so I'm not worried about the
CRCs.

Steph