Network api documentation.

Marcelo Araujo araujobsdport at gmail.com
Thu Aug 22 04:39:02 MDT 2013


2013/8/22 Volker Lendecke <Volker.Lendecke at sernet.de>

> On Thu, Aug 22, 2013 at 01:59:16PM +0800, Marcelo Araujo wrote:
> > Is there any documentation about how samba deal with the physical network
> > interface? How smbd choose the correct interface to establish the session
> > and transfer/receive the data? Also I'd like to understand how could be
> > possible to make samba get advantage of network interfaces with support
> of
> > RSS[1].
> >
> > Looking the source, the only file that I saw till now with something
> > related with physical interface is:
> > samba4/source3/lib/util_sock.c
>
> You might want to take a look at lib/socket/interfaces.c as
> well. This is all spread out a bit, but for incoming
> connections we basically "just" do an accept(). That's it.
>

Yes, in this afternoon I also found lib/socket/interfaces.c as you said.
Thanks to point it out.


>
> Can you describe in higher-level words what behaviour you
> want Samba to exhibit?
>

Sure, I'm looking forward to see smb3 multichannel support, in high level
words this is the behavior that I would like see on samba, and I believe
this is what I understood through Microsoft docs.:

a) NIC with RSS support.
1) Have the capability to check if the NIC provide support to RSS, in case
the NIC has support, it can reply to the client a proper support for
SMB2_CAP_MULTI_CHANNEL.
2) After the client negotiate the SMB2_CAP_MULTI_CHANNEL, the client will
try to open other connections to read/write files simultaneously. If the
server support RSS, the client might try to open new connections as much as
it can. Such like, client read a file(open one connection), client read a
different file(open another connection).

NOTE: The RSS queueing every each connection to a different CPU CORE, that
might improve the connection speed as well as lower the CPU usage. The RSS
in somehow for me right now is done magically by the network driver and I
do believe samba only need open a new smbd with the same session ID, but
with different socket. For every different write or read, we could have
multiples smbd to the same client, thought. The NIC driver will handle the
RSS stuff.

b) NIC without RSS support.
1) If the server has more than one NIC that can reach the same subnet, we
can announce to the client how many interfaces and those respective IP with
SMB2_CAP_MULTI_CHANNEL. As I understood.
2) The client can open multiples connections for read/write different files
as described before on a.2 item. However, there is one difference, the
client will open only two connections, one connection for each NIC.



> > My intention is start to study how to implement multi channel on smb3.
>
> I think Multi-Channel is a large topic that will require
> quite some architectural changes. I would think that
> choosing a proper interface is the smallest of these.
> Do you have a more detailed design in mind?
>

Yes, I have no doubt that you are right, choose the interface is not a big
problem.
I really don't have a clear design yet, due I'm still tracing the code and
doing reverse engineering on Windows 2012.

My main difficult right now is figure out how the code is spread on samba
source tree. And find myself in the middle of those files.

I made a small hack, just to reply to the client(Windows 2012) that we can
support multichannel, however as I cannot make samba handle a new
connection, it will fail anyway. But I can see the client make the
negotiation.

Here attached is a patch with the oldest samba 4.0.4, but the patch is a
crap, it is only for myself to understand and make a proof that it might
work. But, you can point out anything that you want, I'm sure that it will
be helpful.

Thank you so much by your attention.
-- 
Marcelo Araujo
araujo at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multichannel.patch
Type: application/octet-stream
Size: 2652 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130822/72339653/attachment.obj>


More information about the samba-technical mailing list