Re: iSCSI: changing MaxPDUDataLength

["Mallikarjun C." <cbm@rose.hp.com>]

Eddy,

I am not sure if you're agreeing with me or not... but let me add some comments.

I don't expect the change in PDU size to happen frequently - no change
in what I earlier said.

You are making an assumption that a target must record the PDU size for every
PDU  if SNACKs are to be satisfied across changed MaxRecvDataSegmentLength.  
As Julian earlier said, you don't have to.  I will not go into implementation details, but
I believe just the value of the DataSN from which the new size is effective should 
be all that's needed.  Besides, the spec guarantees that only RunLength=0 is used 
on any SNACK after the change.

You are also implying that targets can declare their changed MaxRecvDataSegmentLength
anytime just for writes.  There are two problems with this - a) reads and writes may both
be active in the typical case on an iSCSI connection, and b) a target can declare its changed
value only if an initiator is allowed to start the Text Request (and I thought you were suggesting
that we explicitly disallow that).

Hope that clears it up.
--
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: "Mallikarjun C." <cbm@rose.hp.com>; "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 3:18 PM
Subject: RE: iSCSI: changing MaxPDUDataLength


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