RE: iSCSI: changing MaxPDUDataLength

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

The target would have to quiesc all data-outs anyway before sending the
response (or keep track of PDU sizes which is even worse). I believe this is
easier done at the initiator.

Also, why would one want to do so many PDU size changes that it would really
make a difference?

How are you going to get the offset if the PDU's changed size on you without
keeping track of PDU size changes?

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, June 11, 2002 5:17 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; Julian Satran
Subject: RE: iSCSI: changing MaxPDUDataLength
Importance: High



I think that even the text I suggested is more than it is needed. Quiescing
the connection is not practical - many large box builder will find this
unacceptable and obviously an implementation can go away without it. As I
pointed out for retries you need only the offset at the change point and
anything that happens later require retransmission of everything from the
known point.

Julo


 

                      Eddy Quicksall

                      <eddy_quicksall@i        To:       Julian
Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu                                    
                      vivity.com>              cc:

                                               Subject:  RE: iSCSI: changing
MaxPDUDataLength                                              
                      06/11/2002 08:56

                      PM

                      Please respond to

                      Eddy Quicksall

 

 




I 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