Re: iscsi : Fragmentation & Reassembly issues in iSCSI.

[julian_satran@il.ibm.com]

Santosh,

The intent was to enable lower limits for ping and text.  I would be
reluctant to use the same limit as in some contexts the PDU limit could be
practically very large. PDU will be limited at first by 2 factors - the CRC
and the need to limit loss-of-framing temporary memory.
If and when the underlying transport will have a good RDMA mechanism and we
will have a decent CRC-64 or we are using IPsec the PDU limit could be
extremely large.
We don't want the same to hold for Ping, Text etc.

However we would like to have the PDU limit to hold for all as it is mainly
meant for framing and CRC.

For all those reasons I suggest limiting the text length also to the lower
of the two.

Julo

Santosh Rao <santoshr@cup.hp.com> on 19/01/2001 23:59:49

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  Re: iscsi : Fragmentation & Reassembly issues in iSCSI.




julian_satran@il.ibm.com wrote:

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

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.


> 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>

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