RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

I actually use 512 in my code because I know it won't be used. I gave this
example because the current definition of Irrelevant implied that it was
acceptable.

I think the definition for Irrelevant should be improved. But, if everyone
else is fine with it, I'll accept that.

Eddy


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, February 07, 2002 6:00 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; Julian Satran
Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?


It can give any legal value. Why should we add rules?  Is something wrong
having a value that is not used?

Julo


 

                    Eddy Quicksall

                    <Eddy_Quicksall@iv       To:     Julian
Satran/Haifa/IBM@IBMIL,             
                    ivity.com>                ips@ece.cmu.edu

                                             cc:

                    07-02-02 13:56           Subject:     RE: ips : Is
FirstBurstSize valid when
                                              InitialR2T=yes ?

 

 

 




Given that the target can't do immediate or unsolicited, should it give
"Irrelevant" as the answer? I.e.:

T->I FirstBurstSize=Irrelevant, InitialR2T=yes, ImmediateData=no

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, February 06, 2002 11:39 PM
To: ips@ece.cmu.edu
Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?


Why should we?  The way it is the parameters can be checked without
relation one to another.
The is no logical flaw in having FirstBurstSize <> 0 and no use for it.

Julo




                    Santosh Rao

                    <santoshr@cup.       To:     Eddy Quicksall
<Eddy_Quicksall@ivivity.com>
                    hp.com>              cc:     IPS Reflector
<ips@ece.cmu.edu>
                    Sent by:             Subject:     Re: ips : Is
FirstBurstSize valid when
                    owner-ips@ece.        InitialR2T=yes ?

                    cmu.edu





                    06-02-02 23:32









I think this needs changing then. There's no reason the following
should'nt be allowed :

I -> T :
           InitialR2T=no
           ImmediateData=yes
           FirstBurstSize=65536

T -> I :
           InitialR2T=yes
           ImmediateData=no
           FirstBurstSize=0

Julian :
Can we change the allowed valid range for FirstBurstSize from :

FirstBurstSize=<number-512-to-(2**24-1)>

to :

FirstBurstSize=<number-0-to-(2**24-1)>


- Santosh


Eddy Quicksall wrote:
>
> Draft 10 says:
>
> FirstBurstSize=<number-512-to-(2**24-1)>
>
> So that means you can't send a 0, doesn't it?
>
> Eddy
>
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Wednesday, February 06, 2002 3:01 PM
> To: Fischer, Michael
> Cc: 'Eddy Quicksall'; IPS Reflector
> Subject: Re: ips : Is FirstBurstSize valid when InitialR2T=yes ?
>
> IMO, the FirstBurstSize key value negotiated during login is a don't
> care if *BOTH* immediate data and un-solicited data have been disabled.
>
> However, if the target knows up-front that it does not support either
> immediate or un-solcited and it receives the key FirstBurstSize during
> login negotiation, it should return a 0 value as the result of the
> negotiation for FirstBurstSize.
>
> (Note that the special semantics of 0 implying no limit is no longer
> true for FirstBurstSize and hence, the target can just return 0 iff both
> immediata data and un-solicited data are disabled in login negotiation.)
>
> - Santosh
>
> "Fischer, Michael" wrote:
> >
> > What if the sequence is as follows:
> >
> > I->T    FirstBurstSize=512; T=0; NSG=CSG;
> > T->I    FirstBurstSize=512; T=0; NSG=CSG;
> > I->T    InitialR2T=no, ImmediateData=no; T=1; NSG=FULL
> >
> > If the target does not support InitialR2T=no..  Does login now fail?
> There
> > does not seem to be a way for the target to say that it requires R2T.
Why
> > did the Initiator send FirstBurstSize if it was setting InitialR2T to
no?
> > There is no negotiation with an AND function.
> >
> > Michael Fischer
> >
> > -----Original Message-----
> > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> > Sent: Wednesday, February 06, 2002 9:47 AM
> > To: Santosh Rao; IPS Reflector
> > Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> >
> > That is how I am interpreting it.
> >
> > BTW: How about this one ...
> >
> > I->T FirstBurstSize=512, InitialR2T=no, ImmediateData=no
> >
> > If the target does not support InitialR2T=no, how should it respond to
> > FirstBurstSize?
> >
> > Should the target do this (for draft >= 9)?
> >
> > T->I FirstBurstSize=irrelevant, InitialR2T=yes, ImmediateData=no
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Tuesday, February 05, 2002 2:56 PM
> > To: IPS Reflector
> > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ?
> >
> > Hello,
> >
> > Can someone clarify if the login key FirstBurstSize is valid when :
> > InitialR2T=yes  and ImmediateData=yes ?
> >
> > i.e. if immediate data is enabled and un-solicited data is disabled
> > during login negotiation, is the value of FirstBurstSize received in
the
> > login response to be interpreted ?
> >
> > My current understanding is that FirstBurstSize is inclusive of the
> > immediate data portion, and so, if immediate data is enabled, but
> > un-solicited data is disabled, then, FirstBurstSize *must* be valid and
> > must be <= DataPDULength. (after rev 09, it would be <=
> > (MaxRecvPDULength - the header components size)).
> >
> > For example, a target implementation may offer a FirstBurstSize <
> > DataPDULength, in which case, the immediate data size is the
> > MIN(DataPDULength, FirstBurstSize, bytes_to_send).
> >
> > Can someone clarify if this is a correct interpretation or set me right
> > on this ?
> >
> > Thanks,
> > Santosh


--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################