Re: Unsolicited Data.

["Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <sbhagat@tripace.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
> >
>
>