Subject: Re: iscsi : Fragmentation & Reassembly issues in iSCSI.

From: [email-masked]
Date: Fri, 19 Jan 2001 17:13:45 +0200

answers in text - Julo

Santosh Rao <[email-masked]> on 19/01/2001 02:47:05

Please respond to Santosh Rao <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iscsi : Fragmentation & Reassembly issues in iSCSI.

Julian,

Issue :
=====
DataPDULength, PingMaxReplyLength, Fragmentation/Reassembly issues.

Problem :
=======
1) What is the relationship b/n DataPDULength and PingMaxReplyLength ?

If a simple iSCSI test program decided to use the NOP-OUT as a form of
basic testing and began issuing increasing sizes of NOP-OUT, at some
point, it will cross the DataPDULength  PDU size (provided it was able
to negotiate PingMaxReplyLength > DataPDULength, which such a test
program would attempt, in the interests of large I/O testing).

<js> I will introduce in 04 a statement saying that that PingMaxRelayLength
will be limited by the lowest of the two </js>

The DataPDULength introduces fragmentation and reassembly issues at the
iSCSI layer for the NOP-OUT, NOP-IN and Login commands.

(For the SCSI Data PDUs, reassembly is possible based on the Buffer
Offset contained in the data PDU header.)

Question :
========
What drives the fundamental requirement for the DataPDULength ? I see no
benefit for this other than trying to ensure a small data payload in
order to have an effective CRC. Are there any other benefits ?

<js> data multiplexing on a connexion is the other reason. Unsolicited data
are the only case you are not allowed to multiplex in order to avoid
deadlocks. A good resync mechanism, whenever will become available can also
operate effectively only on limited sizes unless you use a full-fledged
RDMA scheme. Everywhere those reasons are no relevant you can set the
maximum sizes to you memory available. And the maximum ULP PDU is not the
TCP MTU.</js>

Is there a need to impose an upper bound (MTU) on the size of PDUs other
than the SCSI Command PDU (containing immediate data) and SCSI Data PDU
?

Solution :
=======
Specify explicitly in Appendix C that DataPDULength is only applicable
for SCSI Command PDU and SCSI Data PDU. The current definition is open
to being mis-interpreted as a form of iSCSI MTU, something that can
result in the iSCSI layer having to deal with fragmentation and
re-assembly issues for non-SCSI PDUs.

<js> What would be those? Text commands? Login? Nops? Having a single limit
seemms simpler </js>
Regards,
Santosh

 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Fri, 19 Jan 2001 13:59:49 -0800

Julian,

The fragmentation issue as explained in the above example is also applicable
for the Login and Text Commands. (TotalText > DataPDULength).

In the case of these commands, a "F" bit is required in bit 7 of byte 1 of the
command & response PDUs to indicate the last command or response PDU due to
the fragmentation issues that arise from TotalText & DataPDULength.

> <js> What would be those? Text commands? Login? Nops? Having a single limit

On the lines of your above solution, (based on a single limit), removal of
PingMaxReplyLength should be considered and implicitly use DataPDULength as
the PingMaxReplyLength. This ensures only 1 limit for NOP-OUT/NOP-IN.

Regards,
Santosh

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 19 Jan 2001 17:18:15 -0800

It is better to leave a seperate, possibly lower limit for
PingMaxReplyLength

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Santosh Rao
Sent: Friday, January 19, 2001 2:00 PM
To: [email-masked]; [email-masked]
Subject: Re: iscsi : Fragmentation & Reassembly issues in iSCSI.

Julian,

In the case of these commands, a "F" bit is required in bit 7 of byte 1 of
the
command & response PDUs to indicate the last command or response PDU due to
the fragmentation issues that arise from TotalText & DataPDULength.

Regards,
Santosh

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com