SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: changing MaxPDUDataLength




    Rod,

    It is clearly missing. I was thinking at something benign like using it an indication that target wants to negotiate.
    Logout - inititaor is always free to use but it may want to issue a text.

    Julo


    "Rod Harrison" <rod.harrison@windriver.com>

    06/12/2002 02:57 AM
    Please respond to "Rod Harrison"

           
            To:        Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." <cbm@rose.hp.com>
            cc:        <ips@ece.cmu.edu>
            Subject:        RE: iSCSI: changing MaxPDUDataLength

           



                    I'm torn, I don't want to make this sort of change late on but I
    think it would be a good thing in the long term.

                    How about adding the additional async message code and saying upon
    receipt the initiator MAY start a negotiation sequence or logout and
    re-login the connection immediately without having to wait for the
    negotiated timeouts?

                    - Rod

    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Tuesday, June 11, 2002 4:28 PM
    To: Mallikarjun C.
    Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu
    Subject: Re: iSCSI: changing MaxPDUDataLength
    Importance: High



    Mallikarjun,

    The question was general and not specific to MaxRecv....
    Although we say that negotiation is symmetric we don't have any
    mechanism
    through which a target can say it wants to start negotiation something
    (sort of similar but not as strong as a the "request logout" -
    "request to
    negotiate" that will require the initiator to issue a text request and
    kick-off a negotiation.

    Julo



                         "Mallikarjun C."
                         <cbm@rose.hp.com>        To:
    <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
                         Sent by:                 cc:
                         owner-ips@ece.cmu        Subject:  Re: iSCSI:
    changing MaxPDUDataLength
                         .edu


                         06/11/2002 10:50
                         PM
                         Please respond to
                         "Mallikarjun C."





    >  I also realized that we don't have "negotiation prompt" from the
    target.
    >  I am not sure that we need one.

    I am not sure about it either.

    My preference is not to add this.  It appears to me that a target does
    have
    the option of dropping the connection today if it can't work with
    non-ULPDU-contained
    segments for too long.  I suspect that the target would do the same if
    (we
    introduced the "negotiation prompt" and) the initiator
    doesn't/couldn't
    honor the
    "negotiation prompt".

    Thanks.
    --
    Mallikarjun

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


    ----- Original Message -----
    From: "Julian Satran" <Julian_Satran@il.ibm.com>
    To: <ips@ece.cmu.edu>
    Sent: Tuesday, June 11, 2002 8:34 AM
    Subject: RE: iSCSI: changing MaxPDUDataLength



    > I suggest the following text in 11.13
    >
    >        A change of MaxRecvDataSegmentLength by an initiator or
    target
    >        becomes effective after all commands preceding the
    negotiation
    >        end-ing request have been processed by the target and their
    status
    >        is acknowledged.
    >
    >  I also realized that we don't have "negotiation prompt" from the
    target.
    >  I am not sure that we need one.
    >  If some of you think we need we may want one additional code in the
    Asynch
    >  Message.
    >  Please comment TODAY.
    >
    >  Julo
    > ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29
    PM -----
    >
    >                       Julian Satran
    >                                                To:      Eddy
    Quicksall
    <eddy_quicksall@ivivity.com>
    >                       06/11/2002 04:04         cc:
    ips@ece.cmu.edu,
    pat_thaler@agilent.com

    >                       PM                       From:    Julian
    Satran/Haifa/IBM@IBMIL
    >                                                Subject: RE: iSCSI:
    changing MaxPDUDataLength(Document link:
    Julian Satran - Mail)
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > That is a fair request - we may slip in a recommendation to that
    effect
    (in
    > chapter 11?)
    >
    > Julo
    >
    >
    >
    >                       Eddy Quicksall
    >                       <eddy_quicksall@i        To:       Julian
    Satran/Haifa/IBM@IBMIL
    >                       vivity.com>              cc:
    ips@ece.cmu.edu,
    pat_thaler@agilent.com
    >                                                Subject:  RE: iSCSI:
    changing MaxPDUDataLength
    >                       06/11/2002 04:28
    >                       AM
    >                       Please respond to
    >                       Eddy Quicksall
    >
    >
    >
    >
    >
    > How about if we say that an initiator must not change the
    MaxPDUDataSize
    > unless it first idles the commands (at least the ones with the R
    bit) or
    if
    > ErrorRecoveryLevel==0?
    >
    > That would simplify target code greatly and would meet the design
    goals;
    > and since it should be rare to change it, it would be of little
    impact to
    > idle the commands for a split second.
    >
    >
    > Eddy
    >       -----Original Message-----
    >       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    >       Sent: Monday, June 10, 2002 8:06 PM
    >       To: Eddy Quicksall
    >       Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
    >       Subject: RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >       I said only that when you change length you can ask for all
    PDUs
    >       after the ack! (no need to keep a tall - the old offsets are
    good
    up
    >       to the hole).
    >
    >       Julo
    >
    >
    >    Eddy Quicksall
    >    <eddy_quicksall@ivivity.com>              To:        Julian
    >                                      Satran/Haifa/IBM@IBMIL
    >                                              cc:
    ips@ece.cmu.edu,
    >    06/11/2002 12:32 AM               pat_thaler@agilent.com
    >    Please respond to Eddy Quicksall          Subject:        RE:
    iSCSI:
    >                                      changing MaxPDUDataLength
    >
    >
    >
    >
    >
    >
    >
    >       Julian,
    >
    >       Another problem here is that the target has to calculate the
    offset
    >       from the DataSN #. And as BegRun can be any value. E.g.,
    BegRun=4
    and
    >       RunLngth=0 means starting DataSN=4, send all the data for that
    >       sequence.
    >
    >       I think it would be a performance hit and waist of memory to
    keep a
    >       tally of all PDU sizes just for an occasional SNACK.
    >
    >       It's not that it can't be done ... it is more that it is messy
    and
    I
    >       think there is a solution that will satisfy the design
    requirements
    >       but keep the software simpler.
    >
    >       Eddy
    >       -----Original Message-----
    >       From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    >       Sent: Saturday, June 08, 2002 10:16 PM
    >       To: Eddy Quicksall
    >       Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu;
    pat_thaler@agilent.com
    >       Subject: RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >       That is not completely accurate.
    >       The only problem is when PDU size decreases and then SNACK
    must be
    >       for all data.
    >       Target can also keep a mapping of numbers/to offsets (the list
    should
    >       be small and if it gets long ask for ack (A-bit).
    >
    >       Julo
    >
    >    Eddy Quicksall
    >    <eddy_quicksall@ivivity.com>             To:
    >    Sent by: owner-ips@ece.cmu.edu    pat_thaler@agilent.com
    >                                             cc:
    ips@ece.cmu.edu
    >                                             Subject:        RE:
    iSCSI:
    >    06/08/2002 10:54 PM               changing MaxPDUDataLength
    >    Please respond to Eddy Quicksall
    >
    >
    >
    >
    >
    >
    >
    >       Thanks,
    >
    >       As a target, I won't be able to let it change until all of the
    >       outstanding
    >       commands are finished (running with ErrorRecoveryLevel>=1).
    This is
    >       because
    >       I must use the PDU size to compute the offset from a SNACK's
    >       BegRun/RunLength.
    >
    >       So, I plan to not give the text response for a
    MaxPDURecvDataLength
    >       in FFP
    >       until I get back an ExpStatSN == next StatSN.
    >
    >       This will cause a delay of unknown time before the PDU size
    can
    >       actually
    >       change ... do you see any problem with this?
    >
    >       Eddy
    >
    >       -----Original Message-----
    >       From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
    >       Sent: Friday, June 07, 2002 1:13 PM
    >       To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
    >       Subject: RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >       Eddy,
    >
    >       If one uses a message sync and steering that relys on the
    transport
    >       segments
    >       carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then
    if
    the
    >       path
    >       MTU changes one would want to change the PDU data length to
    fit the
    >       new path
    >       MTU.
    >
    >       Pat
    >
    >       -----Original Message-----
    >       From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
    >       Sent: Wednesday, June 05, 2002 12:24 PM
    >       To: ips@ece.cmu.edu
    >       Subject: iSCSI: changing MaxPDUDataLength
    >
    >
    >       Does anybody know a case where it is necessary to support a
    new PDU
    >       data
    >       length during full feature phase?
    >
    >       Eddy
    >       mailto: Eddy_Quicksall@iVivity.com
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >









Home

Last updated: Wed Jun 12 18:18:46 2002
10729 messages in chronological order