|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI:flow control, acknowledgement, and a deterministic reco veryDavid, Resource "stress" is the same as for immediate marked with 0 - as immediate commands are not controlled by a window in any case. The "new scheme" might use a flag and the CmdSN field will carry the next CmdSN (immediate commands will not cause the counters to advance - but 0 does not advance either). The effect you get is that the target will have a "reference point" in the ordered stream where it was supposed to act. For some commands that could be important for other s not. Obviously the immediate commands get ordered with reference to non-immediate commands but not between themselves if issued without intervening ordered commands (a partial order). Obviously I will have to reformulate the "rules of engagement" for command retry but I think it worth doing. And yes - there is no free lunch - I will have to put in some work -:) Thanks for keeping the subject up long enough for me to get the feeling that it might be a problem (and simple solution) out there. Regards, Julo Black_David@emc.com on 09/04/2001 17:11:44 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI:flow control, acknowledgement, and a deterministic reco very > The main reason for selecting 0 and not a flag for immediate delivery was > to enable immediate delivery even when the command window is closed. > > However we can achieve the same effect by using an immediate flag and > using the current CmdSN without advancing it. With this we get a > reference to where in the stream the command where supposed to act if the > stream order is important. I think this causes resource management complications on the target because reusing the CmdSN for an immediate command requires a new command buffer, unless we allow the target to arbitrarily reject/abort some command to make room, which seems wrong (the immediate command may not be a task management command, and even then arbitrary rejects/aborts may not be desirable). How is this better than requiring the Initiator to not permit the command window to close (i.e., the Initiator always keeps one slot in the window open for one immediate command, or N slots for N immediate commands, or no slots if it wants to live dangerously)? I think existing (SCSI and FC) Initiators have to do this sort of resource management anyway, as I don't believe immediate commands are exempt from TASK_SET_FULL. There appears to be a "no free lunch" principle here in that some piece of the iSCSI Initiator-Target system somewhere has to be cognizant of the fact that resources for immediate commands are being reserved on the target, and Initiator control of the command window (coupled with a requirement that MaxCmdSN never decrease) seems to be the easiest way to get there. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Tue Sep 04 01:05:08 2001 6315 messages in chronological order |