Re: ISCSI: Unsolicited data in draft v12

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

Julian,

I know I am at the risk of sounding repetitive.....

> 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.

Completely agreed, that wasn't the point I was making (in fact, I said
there isn't any difference b/n unsolicited and solicited buffers).

My only concern is that the lack of determinism on the usage of pre-allocated
buffers may eventually end up discouraging the adoption of unsolicited
data as a generally implemented feature.

Having expressed my preference, I don't want to make this an issue delaying 
rev12 either.  I will leave it up to you to make the call.  Thanks.
--
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: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <ips@ece.cmu.edu>; "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
Sent: Monday, April 08, 2002 10:16 PM
Subject: Re: ISCSI: Unsolicited data in draft v12


> 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
> >
> >
> >
> >
> >
> 
> 
> 
>