Re: [PATCH 06/11] CIFS: Respect MaxMpxCount field

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sat, 3 Mar 2012 21:14:19 -0600
Steve French <smfrench@xxxxxxxxx> wrote:

> 
> On the issue of why Samba didn't up maxmpx, I expect it is simply that
> until Jeff fixed async read/write, it was rare for a client to send 50
> requests in parallel.
> 

Are windows clients hard capped at 50 outstanding calls or so?

> On the SMB2 credits vs. CIFS maxmpx topic ...  more than once at the
> MS Plugfest I heard pushback on treating SMB2 credits and CIFS maxmpx
> similarly - they are totally unrelated.  SMB2 credits are pretty
> straightforward - we get them back on every request so they are
> constantly changing, but the rules are easier to understand (and are
> well documented, where the CIFS maxmpx behavior is only partially
> documented).
> 

I can understand their POV, and that may be correct. I think we ought
to step back though and consider the fundamental problem that we're
trying to solve. When we want to send a call on the wire, we need to
know:

"Is this particular call allowed to go out onto the wire at this time
or does it need to wait for another event to occur?"

Earlier, I suggested: "Let's treat SMB1 maxmpx handling as a trivial
case of SMB2 credits." If that's not possible for some reason then we
ought to consider something like this:

"Let's build this out the transport layer so that it can accomodate
both sets of protocols by allowing us to plug in different rules
depending on the protocol."

Now that we're looking more closely at this, I think you're correct
that SMB1 maxmpx limits and SMB2 credits follow different "rules". But
I also think that it's best to engineer this in such a way that we can
"plug in" the correct ruleset for answering the above question based on
the protocol version in use.

The trick is to do this in such a way that we only "plug in" what needs
to be different. If treating SMB1 maxmpx limits as a trivial case of
SMB2 credits is too difficult, then I would take that as a sign that we
just need to expand how much of that decision making needs to be
protocol specific.

-- 
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


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux