|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: changing MaxPDUDataLengthI see a case where the target could still end up sending PDU's of different lengths for a given command. It would be much safer if the initiator was required to idle the commands before sending the new MaxRecvDataSegmentLength. That way there is nothing for the target to do other than change the size. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, June 11, 2002 11:34 AM To: ips@ece.cmu.edu Subject: RE: iSCSI: changing MaxPDUDataLength Importance: High 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: Tue Jun 11 19:18:46 2002 10670 messages in chronological order |