Re: Unsolicited Data.

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

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
>