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) -- Thanks, Steve -- 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
