Re: Unsolicited Data.

["Mallikarjun C." <cbm@rose.hp.com>]

Sanjeev,

You seem to restate what I proposed at the bottom of this email.

Yes, the current draft doesn't talk about F-bit setting when immediate
data is not present.  That's precisely what my proposal attempts to 
make use of - to signal "no unsolicited data" if the F-bit is set.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


>Mallkarjun,
>
>According to me it is possible for initiator **not** to send  unsolicited
>data if we follow the latest changes on the section 2.3.1 posted at
>
>According to me
>
>When IntitialR2T= No, Immediate Data = Yes and target doesnt want to
>send any immediate data but it does want to send unsolicited data it can be
>done like this
>Step 1
>Send iSCSI CmdPDU and  Dont send F bit and Dont send any immediate data by
>not including any extra length in datasegmentlength
>Step 2
>Send Unsolicited Data and set the F bit
>
>
>When IntitialR2T= No, Immediate Data = Yes and target doesnt want to
>send any immediate data nor does it want to send unsolicited data it can be
>done as follows
>
>Set F bit in Task and Flag Attributes and dont send any immediate data
>by not including any extra length in datasegmentlength .
>
>My only doubt here is that it is not any illegal condition to set this F bit
>when there is no immediate data to be sent and no unsolicited data to be
>sent. Current spec doesnt declare it illegal but it doesnt really suggest it
>this way either.
>
>
>PLEASE DO COMMENT ON THIS
>
>Regards,
>Sanjeev
>
>
>
>
>----- Original Message -----
>From: "Mallikarjun C." <cbm@rose.hp.com>
>To: <steph@cs.uchicago.edu>
>Cc: <ips@ece.cmu.edu>
>Sent: Thursday, June 07, 2001 8:04 PM
>Subject: Re: Unsolicited Data.
>
>
>> Steph,
>>
>> I agree with you that mandating unsolicited data to be sent always
>> is limiting, even if InitialR2T=no is negotiated.
>>
>> I suggest the following for consideration -
>> - If the command F-bit is set:
>>        - if immediate data is present, it's all the data
>>          for the command. (as in rev06)
>>        - if immediate data is not present, there are no
>>          unsolicited data PDUs following.
>> - If the command F-bit is not set:
>>        - if immediate is present, there is more solicited
>>          data to follow.
>>        - if immediate data is not present, there may be
>>          solicited data depending on "Expected Data Transfer
>>          Length".
>>
>> The only case this disallows is that of having _both_ unsolicited
>> separate PDUs and immediate data for a command - which I personally
>> am okay with.  This is disallowed in rev06 anyway, but for some
>> reason seemed like was changed later.
>> --
>> Mallikarjun
>>
>>
>> Mallikarjun Chadalapaka
>> Networked Storage Architecture
>> Network Storage Solutions Organization
>> MS 5668 Hewlett-Packard, Roseville.
>> cbm@rose.hp.com
>>
>> >
>> >Sanjeev,
>> >
>> >> why would initiator choose not to send unsolicited immediate data when
>> >> it has negotiated for IntialR2T= Yes??
>> >
>> >I assume you mean InitialR2T=no.
>> >
>> >I would do this because I think that the real benefit of unsolicited
>> >data is for writes where ALL the write data can be sent unsolicited,
>> >and I'm happy to have the target schedule the transfer of (ALL) data
>> >for larger writes.  Of course, others would say I'm a moron.
>> >
>> >Assuming the overwhelming majority of storage use is file access,
>> >small writes are exclusively file system metadata writes.  Unsolicited
>> >data is a huge win for metadata writes because the latency of these
>> >metadata writes is frequently not covered by transferring other data
>> >(within a single access thread).  On the other hand, the file system
>> >(usually) generates enough concurrent demand for real data writes that
>> >the flow control (R2T) latency is well hidden.
>> >
>> >You might argue that if you're running a file system optimized fors
>> >today's SANs over a link with a HUGE bandwidth * delay product
>> >(greater than the expected demand created by the file system), sending
>> >large amounts of unsolicited write data will substantially improve the
>> >link utilization.  That is true, but I don't think many targets are
>> >going to offer unsolicited data bursts remotely that large.
>> >
>> >In a hardware accelerate implementation, unsolicited data will be
>> >handled differently than solicited data.  The target can chose where
>> >the solicited data is delivered, but unsolicited data arrives through
>> >a general-delivery path.  Therefore, if the offered unsolicited data
>> >burst size approaches the regular burst size, an implementation will
>> >need TWICE as much buffer memory (half in the general-delivery area
>> >and half in the flow-controlled buffer area) to support the same
>> >operation load.  Maybe this tradeoff is OK, but given the cost
>> >sensitivity of storage targets, I doubt it.
>> >
>> >As always, I welcome comments from those who see things differently.
>> >
>> >Steph
>> >
>>
>>
>