Re: [PATCH v3 00/16] SMB 2.1/3 multicredit requests for reading/writing

["Stefan (metze) Metzmacher" <metze-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

Hi Pavel,

> 2014-07-29 0:14 GMT+04:00 Stefan Metzmacher <metze-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>:
>> Hi Pavel,
>>
>>> The goal of this patchset is to add large MTU/multicredits support for reading and writing from the CIFS client to servers > that support SMB 2.1 and higher versions of the protocol.
>>
>> Are looking at the returned capabilities from the server or just the
>> dialect?
>> The answer should really be the capability, it's wrong to rely on the
>> dialect...
>>
>> metze
> 
> Hi Stefan,
> 
> The code of the patchset is looking at the returned
> MaxReadSize/MaxWriteSize values from the server. If they are greater
> than 64K, the module uses multicredit requests. Also it only works for
> SMB 2.1 and higher versions and is disabled for SMB2.0.
> 
> The spec says (http://msdn.microsoft.com/en-us/library/cc246768.aspx):
> 
> "If the common dialect is SMB 2.1 or 3.x dialect family and the
> underlying connection is either TCP port 445 or RDMA,
> Connection.SupportsMultiCreditMUST be set to TRUE; otherwise, it MUST
> be set to FALSE."
> 
> So, it seems like the server must should multicredit requests if
> negotiating SMB 2.1 or 3.x protocols.
> 
> Anyway, if the server sets MaxRead(Write)Size value to more than 64K
> and does not support multicredit requests, this server looks like a
> broken one.
> 
> I can add a check for MTU capability bit for SMB 2.1 and 3.x protocols
> before the check of MaxRead(Write)Size value and let the code fall
> back to the 64K per request if this bit is missed.

I'd prefer to have this extra check, you never know if some vendors are
crazy
enough to run Samba 4.0.0alpha* release. Samba got SMB2.1 support in
September 2011
and multi-credit support in February 2012.

metze



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 246 bytes --]