On Thu, 5 May 2011 21:38:47 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, May 4, 2011 at 6:09 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Wed, 4 May 2011 14:38:07 +0400 > > Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > > > >> 2011/5/2 Jeff Layton <jlayton@xxxxxxxxxx>: > >> > Currently, we have a default cap of 50 outstanding requests and a hard > >> > cap of 256. However, the server sends us how many requests it can handle > >> > simultaneously via the MaxMapCount value in the NegProt request. Use > >> > that value instead and eliminate the cifs_max_pending module parm. > >> > > >> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > >> > >> > >> If we ignore this limit for Echo request, can a server drop a > >> connection if we send, e.g. maxReq write requests and 1 Echo request? > >> http://msdn.microsoft.com/en-us/library/ee441946(v=PROT.13).aspx > >> doesn't mention about any exceptions for Echo request in this case. > >> > > > > Well, we currently ignore this for oplock breaks too... > > > > I suppose we probably ought to have a small number of slots kept in > > reserve for echoes and oplock breaks. Instead of just ignoring the > > limit for those we can allow these calls access to those "emergency" > > slots. > > Two reserved slots: 1 for oplock break, 1 for echo. > > 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) > Right. I think I'm just going to end up dropping this patch from the set. It's not really required for this and it probably deserves to be a separate set of patches. -- 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
