Re: ISCSI: Unsolicited data in draft v12

["Julian Satran" <Julian_Satran@il.ibm.com>]

Mallikarjun,

I understand all those arguments. However I assume that a target is deigned to handle a certain number of commands.
If the commands come without unsolicited data buffers are immediately available for R2T.

A good argument against removing the restriction is that at the target solicited data require more processing than unsolicited data and this is generally a resource an initiator shares with others and we should not encourage him to behave badly.

However since we do not mandate unsolicited data I do not see how leaving the initiator to make the decision on a task basis would affect the target and the initiator will not do it indiscriminately anyhow because it takes a performance hit for using solicited data.

And thanks for 9.3.5. 

Julo

"Mallikarjun C." <cbm@rose.hp.com> 09-04-02 02:15 Please respond to "Mallikarjun C."

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        <ips@ece.cmu.edu>, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>         Subject:        Re: ISCSI: Unsolicited data in draft v12

Julian,

I didn't read Matthew's note as saying that implementations keep
separate buffers for solicited and unsolicited data.

I think the issue is that the target may need to reserve the buffers
for unsolicited data *apriori* for whatever command window credit
it had announced.  This reservation may actually constrain the max
credit that the target announces - and if the reserved buffers are not
used eventually, targets may not be as motivated to support unsolicited
data, or may seriously underprovision buffers (and use R2T to recoup
discarded data, if initiator does send unsolicited data for all commands)
- either of which would defeat the performance benefits intended by
this feature in the first place.

I recommend that we stay with the new tightened wording in section
2.2.4 of 11-91.  BTW, section 9.3.5 needs to be sync'ed with this
(it still uses SHOULD) - or ideally should refer back to 2.2.4.

My 0.02.
--
Mallikarjun

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

----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Cc: <ips@ece.cmu.edu>; "'John Hufferd'" <hufferd@us.ibm.com>; "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
<matthew_burbridge@hp.com>; <owner-ips@ece.cmu.edu>; "Rod Harrison" <rod.harrison@windriver.com>
Sent: Monday, April 08, 2002 12:00 PM
Subject: RE: ISCSI: Unsolicited data in draft v12


> I am with John here (the third guy that is right) - why would an
> implementer have separate buffers for solicited and unsolicited data?
>
> Julo
>
>
>
>
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
> 08-04-02 21:43
> Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
>
>
>         To:     John Hufferd/San Jose/IBM@IBMUS, "BURBRIDGE,MATTHEW
> (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
>         cc:     Julian Satran/Haifa/IBM@IBMIL, Rod Harrison <rod.harrison@windriver.com>,
> ips@ece.cmu.edu, owner-ips@ece.cmu.edu
>         Subject:        RE: ISCSI: Unsolicited data in draft v12
>
>
>
> John,
>
> It's not so much an implementation problem but one resource management
> problem in that if unsolicited data has been negotiated then target MUST
> pre-allocate buffers with which to store the unsolicited when it arrives.
> The target implementors will decided whether they want to use unsolicted
> data and take the buffer resource hit in doing so.  However, if they do
> wish
> to take this hit but the initators decide not to use unsolicited data
> (even
> though they have negotiated to use it) then there is potientially a lot of
> valuable buffer resources tied in up for unsolicited data but which is not
> being used.
>
> Matthew
>
> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Monday, April 08, 2002 11:13 AM
> To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Cc: 'Julian Satran'; Rod Harrison; ips@ece.cmu.edu;
> owner-ips@ece.cmu.edu
> Subject: RE: ISCSI: Unsolicited data in draft v12
>
>
>
> Please explain, why an initiator deciding to not send unsolicited data for
> a specific command causes an implementation problem.  That was not clear
> from your statements.  You still need the R2T capability, so what is lost?
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
>
>
> "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
> @ece.cmu.edu on 04/08/2002 10:25:55 AM
>
> Sent by:    owner-ips@ece.cmu.edu
>
>
> To:    "'Julian Satran'" <Julian_Satran@il.ibm.com>, Rod Harrison
>        <rod.harrison@windriver.com>
> cc:    ips@ece.cmu.edu, owner-ips@ece.cmu.edu
> Subject:    RE: ISCSI: Unsolicited data in draft v12
>
>
>
> I must express my concern on this issue.  From a target point of view once
> it has negoiated the use of unsolicited data it has to allocate buffer
> space
> for that unsolicited data.  Now depending on the various parameters this
> may
> be a sizeable chunk of valuable resources which it is making available.
> Now
> if the decision to use unsolicited data is being moved from a per session
> to
> per task basis (which is what this change effectively does) then it puts
> an
> awful lot of resource overhead on the target which may never be used.
>
> For the reasons above I propose that we do not relax the v12 restriction
> and
> keep it as:
>
> "An iSCSI initiator MUST send as unsolicited data either the negotiated
> amount or all the data if the total amount is less than the negotiated
> amount for unsolicited data."
>
> Matthew Burbridge
> Principal Engineer
> NSAS-Bristol
> Hewlett Packard
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, April 08, 2002 9:36 AM
> To: Rod Harrison
> Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: ISCSI: Unsolicited data in draft v12
>
>
>
> OK - Julo
>
>
> "Rod Harrison" <rod.harrison@windriver.com>
> Sent by: owner-ips@ece.cmu.edu
> 08-04-02 14:52
> Please respond to "Rod Harrison"
>
>         To:        <ips@ece.cmu.edu>
>         cc:
>         Subject:        ISCSI: Unsolicited data in draft v12
>
>
>
>
>
>                 I propose we slightly relax the new restriction in draft
> v12
> that the
> initiator MUST send the maximum permissible amount of unsolicited data. I
> suggest we change the rule to allow the initiator to either send no
> unsolicited data, or the maximum permissible.
>
>                 There is no difficulty for the target here since the lack
> of
> unsolicited
> data will be clearly indicated by a command PDU with F bit set and
> dataSegLen=0. The target will have all the information it needs to
> immediately issue R2Ts as appropriate.
>
>                 I believe the initiator should be able to make a policy
> decision on which
> individual commands should be sent with unsolicited data and which should
> not.
>
>                 In draft 11.91 section 2.2.4 I suggest we change
>
> "An iSCSI initiator MUST send as unsolicited data either the negotiated
> amount or all the data if the total amount is less than the negotiated
> amount for unsolicited data."
>
>                 to something like
>
> "An iSCSI initiator MAY choose to send no unsolicited data with a command,
> or if any unsolicited data is sent it MUST be either the negotiated amount
> or all the data if the total amount is less than the negotiated amount for
> unsolicited data."
>
>                 - Rod
>
>
>
>
>