SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: checking immediate data



    John,

     

    I also agree that this particular case is not a performance issue.

     

    I tried to indicate below that the premise of making this type of requirement can be extended to many other cases and if the premise is acceptable, where do you stop? (E.g., one person's flag may require a memory access but another person's flag may not - don't forget also that the performance path may be running in on chip memory that is small, so extra code to support unnecessary requirements is not a good idea)? IMHO, a spec should not make these kinds of statements in a performance path.

     

    Eddy

     

    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Friday, August 08, 2003 11:00 AM
    To: Eddy Quicksall
    Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject: RE: checking immediate data

     


    Eddy,
    I guess I do not put this trivial immediate data check in the same league as some of the other possible performance path checks.  I do not think that I can be convinced that checking a "flag" that says that I can or can't accept immediate data will impact the performance path.  And with that in mind, I support David's comments.
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/System Group, San Jose CA
    Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
    Alt Office: (408) 997-6136, Cell: (408) 499-9702
    Internet Address: hufferd@us.ibm.com


     

    Eddy Quicksall <eddy_quicksall@ivivity.com>
    Sent by: owner-ips@ece.cmu.edu

    08/08/2003 06:34 AM

           
            To:        Black_David@emc.com, Julian_Satran@il.ibm.com
            cc:        ips@ece.cmu.edu
            Subject:        RE: checking immediate data




    First, note that I realize it is too late to change this but I just want to
    comment that using that rational, it would seem that the target should be
    checking many other things that the initiator may do wrong. Obviously, that
    would eventually effect performance; and this thinking is not consistent
    with the consensus on another thread going on here regarding checking the
    ITT for reuse.

    In general, this kind of requirement should not appear in a performance
    path.

    Eddy

    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Friday, August 08, 2003 9:26 AM
    To: Julian_Satran@il.ibm.com; eddy_quicksall@ivivity.com
    Cc: ips@ece.cmu.edu
    Subject: RE: checking immediate data

    Eddy and Julian

    In the current specification, the target requirement also avoids
    an interoperability problem if a broken initiator sends immediate
    data that it has no business sending - since in the absence of the
    requirement, target acceptance of the immediate data will be
    implementation-dependent, the result is an annoying "sometimes
    it works, sometimes it doesn't" situation.

    It's better to have the initiator fail the first time it tries this
    and get fixed, as opposed to building up an installed base where this
    works when it shouldn't, as that would eventually cause removal of
    the ImmediateData negotiation key, as targets would always have to
    accept immediate data to deal with broken initiators who don't
    know how not to send it.

    Thanks,
    --David
    ----------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 176 South St., Hopkinton, MA  01748
    +1 (508) 293-7953             FAX: +1 (508) 293-7786
    black_david@emc.com        Mobile: +1 (978) 394-7754
    ----------------------------------------------------

    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Friday, August 08, 2003 1:25 AM
    > To: Eddy Quicksall
    > Cc: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu); owner-ips@ece.cmu.edu
    > Subject: Re: checking immediate data
    >
    >
    > The reason beyond this was that a 'highly optimized target may have
    > prepared already the R2T. I guess that you are objecting to
    > the second
    > MUST in the sentence  and I guess that except for recovery it
    > is a bit too
    > strong. For recovery however you might end up having a
    > different sequence
    > in recovery vs. original.
    >
    > Regards,
    > Julo
    >
    >
    >
    > Eddy Quicksall <eddy_quicksall@ivivity.com>
    > Sent by: owner-ips@ece.cmu.edu
    > 07/08/2003 19:34
    >
    > To
    > "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" <ips@ece.cmu.edu>
    > cc
    >
    > Subject
    > checking immediate data
    >
    >
    >
    >
    >
    >
    > Section 12.11 says:
    >  
    > If ImmediateData is set to No and InitialR2T is set to Yes, then the
    > initiator MUST NOT send unsolicited data and the target MUST reject
    > unsolicited data with the corresponding response code.
    >  
    >  
    > If the initiator says ImmediateData=No and the target has the
    > capability
    > of taking immediate data BUT the initiator sends immediate
    > data anyway,
    > why should the target be responsible to make that check (as
    > long as it
    > isn't going to break the target)?
    >  
    > Eddy
    >  
    >



Home

Last updated: Fri Aug 08 13:19:26 2003
12809 messages in chronological order