|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI - Change Proposal X bitcomments in text.. Julian Satran wrote: > > That is an interesting proposal. However since it won't work in face of an > initiator that does not actively use the connection (your two prameters > are per/session values determined by the initiator. I am not sure if I am catching this one..I think the problem you are referring to is as follows : When there is no difference between (expStatSN, statSN), the target must ignore "cmdSN_of_last_statSN" and _only_ use "expCmdSN" when growing the maxCmdSN. This involves some form of upcalls from the connection to the session manager. Then this scheme would work, but it gets architecturally complicated, as Mallikarjun already pointed out. Is this what you are also saying ? > > I read Mallikarjun's proposal to add a stricter requirement on activity > and thus avoid cleaning NOPs - as "send some non-immediate request that > requires a response on every connection at least once in 2^31-1 CmdSN to > include anything sent (no additional traffic). > > I intended to something close to your rule at the target to avoid > increasing the window into the "dangerous zone" while not requiring a > synchronous barrier at the initiator. Curious minds, interested in details .. -Sandeep > > Julo > > sandeepj@research.bell-labs.com (Sandeep Joshi) > Sent by: owner-ips@ece.cmu.edu > 27-10-01 03:08 > Please respond to sandeepj > > > To: cbm@rose.hp.com, ips@ece.cmu.edu > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Mallikarjun, > > This problem can be solved _without_ introducing > any additional I/O activity. Notice that it > occurs because we allow the maxCmdSN to increase > unbounded in the presence of unacked statSNs. > > The target can prevent this from happening. > > Imagine some connection A at the target : > > (1) Everytime the target sends a new statSN out, it > records the cmdSN for that statSN > (say Connection_A.cmdSN_of_last_statSN = 200) > > (2) While growing maxCmdSN at target, ensure that > (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) > > This is stricter than current condition > (maxCmdSN - expCmdSN) < 2^31-1 > > If there are N connections, use least value of > cmdSN_of_last_statSN. > > (3) All retried commands will always fall outside > the window. They will be on the "dark side". > > (4) If the target cant grow maxCmdSN, it closes the > offending connection, or sends out NOPs. > > Works ..? > > -Sandeep > > > In helping others walk through your scenario here in HP, > > we all realized that the core solution to the problem > > is to mandate a complete execution of a numbered command > > (some I/O activity that is trackable) on each connection > > once at least every (2^32 -1) commands. It may be a NOP, > > or any regular command. So, here is my suggestion - > > > > An initiator MUST send at least one non-immediate command > > on each of the connections participating in the session, > > for every (2^31 -1) numbered commands. > > > > Comments? > > -- > > Mallikarjun
Home Last updated: Mon Oct 29 02:17:35 2001 7432 messages in chronological order |