On Fri, 6 May 2011 11:01:52 +0400 Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2011/5/6 Steve French <smfrench@xxxxxxxxx>: > > Two reserved slots: Â Â1 for oplock break, 1 for echo. > > What's if we need to send oplock break for two files in almost the same time? > > > Note that if maxmpx is set to 2 on negotiate, we also have to disable > > oplock (echo + 1 pending open request would max out our maxmpx) > > What's if maxmpx is set to 1? According to the link (that I posted > above) it is a possible situation. > > Note that now we don't count block locking command, but the spec > doesn't tell anything about it - so, I think we should count them too. > Ditto. The blocking lock code is a mess anyway -- that really needs a fundamental re-think. > May be we should drop any exceptions, count all types of requests and > move to smth like priority queue? In this case we can use three kind > of lists and put echo requests into the highest priority list - e.g. > "3", oplock break requests - "2", and all other requests into the > priority "1" list. Or we can use only one double-linked list and put > all echo and oplock break requests to the head, and all other requests > - to the tail. > > Thoughts? > A priority queue doesn't really help here. What if you already have maxmpx calls in flight and suddenly need to send an oplock break? You'll just be stuck. I think all you really need here is a flag for the slot allocator that tells whether some calls are allowed to dip into the emergency pool, and keep a couple of slots in reserve for echoes and oplock breaks like Steve suggests. In practice, there's probably no reason to have more than one echo in flight, and we could modify the echo code not to send one when there's already one that the server hasn't responded to. If the server sends back a maxmpx value less than 2 we should probably fail the mount. Less than 3, and we should disable oplocks. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
