SMB2/3 Credits (Multi-Credit) support

[Jeremy Allison]

On Fri, Jun 29, 2012 at 02:00:39PM +0200, Christian Ambach wrote:
> On 06/27/2012 11:11 PM, Jeremy Allison wrote:
> 
> > I noticed you removed DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR,
> > which is fine, but I need to tell you why that was added.
> >
> > What I observed back when we were advertising smaller credit
> > windows was that Windows clients would request sequence numbers
> > *outside* of the valid credit range.
> >
> > For example, if we have a valid sequence number space of 100-200,
> > then Windows clients would use requests with sequence numbers between
> > 100 - 300. Note that they'd never use more than the 100 outstanding
> > credits they had available, but they'd commonly miss a low
> > sequence number and then use numbers above the valid range,
> > finally filling in the missing low sequence number just before
> > running out of credits.
> >
> >So DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR was a heuristic added
> >to allow us to cope with that. Christian worked with me on
> >this and can probably also remember some details.
> >
> My impression was that this problem went away after some fixes were
> added to Samba, e.g. the ones that make sure that we properly grant
> the requested credits for compound requests (65566df) and granting
> credits in async replies (ffbd1ed). There might be more changes that
> were involved, but I do not recall seeing the message id gap again
> in recent smbd logs I looked into.
> 
> So it seems to me that adding this doubled ranges was more a
> papering over real issues.
> 
> I can re-run the tests that hit the wrong message id messages
> against Metze's patches once I am back in the office in about 10
> days.

Great - thanks Christian ! In the meantime let's get these
fixes back-ported for 3.6.next. It's not good to rely on
the DEFAULT_SMB2_MAX_CREDIT_BITMAP_FACTOR heuristic if it's
not needed.

Cheers,

	Jeremy.