RE: iSCSI: changing MaxPDUDataLength

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

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