SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: ISCSI: Unsolicited data in draft v12



    
    	Ditto on Mallikarjun's last paragraph, I don't feel strongly enough about
    this to have it delay v12 and last call, real or practice.
    
    	- Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Mallikarjun C.
    Sent: Tuesday, April 09, 2002 8:52 PM
    To: Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: Re: ISCSI: Unsolicited data in draft v12
    
    
    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
    > >
    > >
    > >
    > >
    > >
    >
    >
    >
    >
    
    


Home

Last updated: Tue Apr 09 19:18:22 2002
9569 messages in chronological order