|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: changing MaxPDUDataLengthEddy, 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 |