Subject: RE: iSCSI: changing MaxPDUDataLength

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Jun 2002 16:11:00 +0300

That is a fair request - we may slip in a recommendation to that effect 
(in chapter 11?)

Julo

Eddy Quicksall <[email-masked]>
06/11/2002 04:28 AM
Please respond to Eddy Quicksall

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked], [email-masked]
        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:[email-masked]]
Sent: Monday, June 10, 2002 8:06 PM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]
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 <[email-masked]> 
06/11/2002 12:32 AM 
Please respond to Eddy Quicksall 
        
        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        [email-masked], [email-masked] 
        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:[email-masked]]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]> 
Sent by: [email-masked] 
06/08/2002 10:54 PM 
Please respond to Eddy Quicksall 
        
       To:        [email-masked] 
       cc:        [email-masked] 
       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: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 07, 2002 1:13 PM
To: [email-masked]; [email-masked]
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:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
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: [email-masked]

---

From: "Rod Harrison" <[email-masked]>
Date: Tue, 11 Jun 2002 09:46:44 -0500

I don't see an issue with this, although I would prefer to see it
mandated rather than recommended.

	- Rod

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
Sent: Tuesday, June 11, 2002 8:11 AM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]
Subject: RE: iSCSI: changing MaxPDUDataLength

That is a fair request - we may slip in a recommendation to that
effect (in chapter 11?)

Julo

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:[email-masked]]
Sent: Monday, June 10, 2002 8:06 PM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]
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

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:[email-masked]]
Sent: Saturday, June 08, 2002 10:16 PM
To: Eddy Quicksall
Cc: [email-masked]; [email-masked]; [email-masked]
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

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 07, 2002 1:13 PM
To: [email-masked]; [email-masked]
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:[email-masked]]
Sent: Wednesday, June 05, 2002 12:24 PM
To: [email-masked]
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