Network api documentation.

Marcelo Araujo araujobsdport at gmail.com
Thu Aug 29 21:16:01 MDT 2013


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

>
> 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?
>
>
Hello, I'm here once again to talk about smb3(MultiChannel)!
I made some tests during this week with SMB3(MultiChannel) and I would like
to share what I saw.

Two methods can get the multi channel support from client(Windows 2012).
1. Two Interfaces with Teaming NIC.
2. RSS Interface.

1. Two Interfaces:
The client try to establish a second connection, however smbd will start a
second fresh thread that does not share any info about the client SID. I
tried to change smbd code, but I didn't find a good way to let the new smbd
thread access the tdb to catch info about the client session, because the
tdb is locked by the previous smbd thread. (So, I bypass this option now
and hold it for a while till I solve the second part.)

2. RSS:
I have some 10G Intel interfaces that support RSS, I set the RSS bit and
set also 2 queues on server side. The client behavior in this case is
different, the client send a second write command, however the first write
command was not finished yet and it can be a big problem in currently samba
architecture. As I saw, I can't write the data from a not continuous offset.

The steps that I use:
1. Enable the SMB2_CAP_MULTI_CHANNEL when respond the negotiation request.
2. When the client send FSCTL_QUERY_NETWORK_INTERFACE_INFO(0x001401fc)
command, I reply the second network interface or the RSS support.
3. Copy a file to server, the client(windows 2012) start send write command
on first interface and try to negotiate with the second interface. (Dual
NIC case).
4. With the RSS, the client send the second write, but I fail to catch it
on server side, because samba architecture does support only continuous
offset for the write command in my understanding.

I'm thinking how to deal with this not continuous offset on the write
command, and I would like to have some suggestions.

Maybe write a set that will individually take care of the write command,
that would be outside of smbd, the smbd would pass the write offset to this
new thread or process, this new thread/process will have such like a queue
where it will organize the write in a continuous offset. This new
thread/process would handle all write commands from any smbd thread that
has smb3 multichannel negotiated.

I'd like to hear from experienced developers here, if they have any other
suggestion related with the write command.

Marcelo Araujo
araujo at FreeBSD.org


More information about the samba-technical mailing list