RE: iSCSI: changing MaxPDUDataLength

[Eddy Quicksall <eddy_quicksall@ivivity.com>]

You are correct and that is exactly how I have had to code it. With fast
path and slow path code split between processors, it becomes even worse.

When I read your comments on why the PDU size could change (from way back in
March I think), I got did not get the impression that it would happen very
often and that in fact it may only happen when you are maintaining
allegiance to another connection.

If it is something that is not going to happen very often, then it would be
so much easier to have the initiator idle the commands first (all it really
needs to do is idle the READ commands). If it is going to change so often
that idling would be degrading, I suspect that just doing the negotiation
that often would itself be degrading.

And, be aware that the target will probably idle the R commands. Otherwise,
it will have to track PDU sizes and that would be really
"counter-productive" (especially when there should be no SNACKs on a good
connection anyway).

I don't see any problem with the target negotiating its size at any time.
And the initiator would not have to idle the WRITE or no-data commands.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Tuesday, June 11, 2002 3:35 PM
To: Eddy Quicksall; Julian Satran
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: changing MaxPDUDataLength


Eddy,

I am not clear on why you think the target code becomes messy on 
a PDU size change.  The last para in section 4.4 states the following -

"Parameters negotiated by a text exchange negotiation sequence become
effective only after the negotiation sequence is completed."

Since the target gets to complete a text negotiation with a Text Response
PDU, it can time the applicability of a changed MaxRecvDataSegmentLength.

Requiring that an initiator must idle the connection before changing this
parameter, IMHO, is counter-productive when there's a dynamic PMTU
degradation in the presence of long-running commands (writes in particular).
Once the initiator starts the renegotiation, target would ideally want to
quickly 
renegotiate its receive size as well to receive ULPDU-contained segments.

In short, seems to me that the draft is saying what you would like.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: "Eddy Quicksall" <eddy_quicksall@ivivity.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 7:56 AM
Subject: RE: iSCSI: changing MaxPDUDataLength


> 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
> 
> 
> 
> 
> 
> 
> 
>