Status and demo of SMB3 Multi-Channel in Samba
obnox at samba.org
Thu Oct 30 13:46:54 MDT 2014
first of all, thanks for testing our WIP code and looking
at it from the performance perspective.
Note that this first demo is with code that does not have
seen performance tuning of any kind, it is rather meant to
demonstrate that we are able to speak the protocol aspects
of multi channel correctly. That being said, I would exepect
a performance benefit with big I/Os that the windows client's
logic would distibute over multiple channels.
On 2014-10-29 at 18:20 -0700, Linda A. Walsh wrote:
> Michael Adam wrote:
> >we are working on implementing SMB3 Multi-Channel in Samba.
> >The wiki page https://wiki.samba.org/index.php/Samba3/SMB3
> >contains details about our plans for the various items
> >of SMB3, and multi-channel in particular. I have
> >created a screencast of a demo. It can be downloaded here:
> Right now, it appears all of the multi-channel data connections are handled
> by 1 smb process. Note, I try to use b=bits, B=bytes,
> [m,g]=1000-based & [M,G]=1024 based units.
> Initially, I tried using 2-bonded 10gb[s connections for xfer. Note:
> 10gbps only has 80% efficiency, so max theoretical rate would
> be would be 16gbps or 2000mBps; the 20% perf hit doesn't apply
> to most 1Gb adapters.
> For a remote target, I used "nul" and "zero" in a remote
> directory that were connected to the actual /dev/nul and /dev/zero
I hope "/dev/null" instead of "/dev/nul" ?
> Does the multi-channel protocol allow for using more than one server
> (smb) process -- as that seems to be the only way I might achieve
> close to full throughput or make use of channel bonding with 2 or
> more ethernet adapters.
The protocol does not know about smb processes. This is the
implementation. The point with our implementation is that
we loosened Samba's 1:1 correspondence between tcp connections
and smbd child processes to be 1:1 between SMBD client
(identified by client guid) and smbd child process. So that
indeed a multi-channel session will be handled by the same
process. If we were to stick with multiple processes here,
these would have to negotiate various bits about the protocol
and about the filesystem interaction among another, and I'd
expect a lot of overhead from that.
Instead we rely on the pthread-pool based AIO code in smbd
and hence the smbd processes shoudl speread its load out
across multiple processors at least if you set (e.g.)
"aio read size = 1" and "aio write size = 1" as Jeremy
has already indicated in another mail.
Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the samba-technical