Re: ISCSI: Immediate data extending beyond a single PDU

[julian_satran@il.ibm.com]

Pierre,

Barry did not ask for unsolicited data to be eliminated - he rather asked
for immediate to be enabled independent of enabling unsolicited (i.e., you
can have either both - not in the same command obviously - or only
immediate). Do you object to this too?

Regards,
Julo

Pierre Labat <pierre_labat@hp.com> on 09/02/2001 18:56:05

Please respond to Pierre Labat <pierre_labat@hp.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: ISCSI: Immediate data extending beyond a single PDU




Robert Snively wrote:

> I do not see any reason to create the constraint that Pierre
> suggests.  The goal is to negotiate a maximum acceptable buffer
> space always available for unsolicited data up to the length Firstburst.
> If the initiator chooses not to send that much data in the first
> transfer for reasons of its own, it should be allowed to.  The
> performance penalty for the affected transfer is small and does not
> affect over-all throughput.
>
> There should be no architectural limitation demanding that the first
> burst of a transfer greater than Firstburst in length is always equal
> to Firstburst.  In particular, if it isn't, what are you going to do
about
> it, post an error?
>
> Bob
>

Julian, Robert,

I missed the "F" bit in the data PDU. With that, the target
knows when to send the R2T if the unsolicited data
is less than the FirstBurst. Hence, as Julian said
there is no problem for that.
However on the other point, i am against the removal
of the possibility to send unsolicited DATA PDU
(and use only immediate data for unsolicited) because
in the case where small iSCSI PDUs are used, it
may not be possible to send all the unsolicited data
in the command PDU.

Regards,

Pierre