Subject: Re: Unsolicited Data.

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 07 Jun 2001 17:49:36 PDT

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.
[email-masked]

>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." <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>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.
>> [email-masked]
>>
>> >
>> >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
>> >
>>
>>
>

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 08 Jun 2001 10:22:24 -0400

FYI..this has been discussed in an earlier thread.
The final bit would indicate end-of-sequence, and
then enable the target to start sending R2Ts.

see http://ips.pdl.cs.cmu.edu/mail/msg04638.html

And Matt had similar objections (as raised earlier in
this thread) to allowing the initiator the leeway to 
decide if it can (or cannot) send the negotiated amount 
of immediate data. IOW, the draft does not state that
the initiator MUST send the negotiated amount of data.

-Sandeep