SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    >
    
    
    


Home

Last updated: Tue Sep 04 01:04:32 2001
6315 messages in chronological order