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



    Mallikarjun,
    
    The initiator can wait for all outstanding sequences to get acknowledged
    prior to negotiating MaxPDUDataLength change. That will work well for
    long-running commands and simplify target management.
    
    Amir
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Mallikarjun C.
    Sent: Tuesday, June 11, 2002 12:35 PM
    To: Eddy Quicksall; Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: Re: iSCSI: changing MaxPDUDataLength
    
    
    Eddy,
    
    I am not clear on why you think the target code becomes messy on
    a PDU size change.  The last para in section 4.4 states the following -
    
    "Parameters negotiated by a text exchange negotiation sequence become
    effective only after the negotiation sequence is completed."
    
    Since the target gets to complete a text negotiation with a Text Response
    PDU, it can time the applicability of a changed MaxRecvDataSegmentLength.
    
    Requiring that an initiator must idle the connection before changing this
    parameter, IMHO, is counter-productive when there's a dynamic PMTU
    degradation in the presence of long-running commands (writes in particular).
    Once the initiator starts the renegotiation, target would ideally want to
    quickly
    renegotiate its receive size as well to receive ULPDU-contained segments.
    
    In short, seems to me that the draft is saying what you would like.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions
    Hewlett-Packard MS 5668
    Roseville CA 95747
    cbm@rose.hp.com
    
    
    ----- Original Message -----
    From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
    To: "Julian Satran" <Julian_Satran@il.ibm.com>
    Cc: <ips@ece.cmu.edu>
    Sent: Tuesday, June 11, 2002 7:56 AM
    Subject: RE: iSCSI: changing MaxPDUDataLength
    
    
    > I think it should be a requirement because if it is not, all target code
    > will have to have the messy code. Or, we could say that if it is not idle
    > commands, then the target may reject it.
    >
    > Eddy
    >
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Tuesday, June 11, 2002 9:11 AM
    > To: Eddy Quicksall
    > Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
    > Subject: RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >
    > That is a fair request - we may slip in a recommendation to that effect
    (in
    > chapter 11?)
    >
    > Julo
    >
    >
    >
    > Eddy Quicksall <eddy_quicksall@ivivity.com>
    >
    >
    > 06/11/2002 04:28 AM
    > Please respond to Eddy Quicksall
    >
    >
    >
    >         To:        Julian Satran/Haifa/IBM@IBMIL
    >         cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
    >         Subject:        RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >
    >
    > 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>
    >
    >
    > 06/11/2002 12:32 AM
    > Please respond to Eddy Quicksall
    >
    >
    >        To:        Julian Satran/Haifa/IBM@IBMIL
    >        cc:        ips@ece.cmu.edu, pat_thaler@agilent.com
    >        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>
    > Sent by: owner-ips@ece.cmu.edu
    >
    >
    > 06/08/2002 10:54 PM
    > Please respond to Eddy Quicksall
    >
    >
    >       To:        pat_thaler@agilent.com
    >       cc:        ips@ece.cmu.edu
    >       Subject:        RE: iSCSI: changing MaxPDUDataLength
    >
    >
    >
    >
    >
    >
    > 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: Tue Jun 11 20:18:48 2002
10674 messages in chronological order