RE: iSCSI: changing MaxPDUDataLength

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

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