|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: checking immediate dataDavid, I agree and that is why we have it (if I can recall correctly). But although we don't intend to do anything we should commiserate with the purists :-) Regards, Julo Black_David@emc.com 08/08/2003 16:26 To Julian Satran/Haifa/IBM@IBMIL, 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 |