Work in progress SMB-Direct driver for the linux kernel

[Steve French]

On Sun, Feb 4, 2018 at 10:39 AM, Doug Ledford <dledford at redhat.com> wrote:
> On Thu, 2018-02-01 at 10:52 -0700, Jason Gunthorpe wrote:
>> On Thu, Feb 01, 2018 at 09:18:10AM +0100, Stefan Metzmacher wrote:
>>
>> > The first goal is to provide a socket fd to userspace (or in kernel
>> > consumers)
>> > which provides semantics like a TCP socket which is used as transport
>> > for SMB3. Basically frames are submitted with a 4 byte length header.
>>
>> Part of the point of RDMA is that we don't need to make protocol
>> specific kernel modules like this - is there a specific reason this
>> needs to be in the kernel like this?
>
> Although your question was partially answered, I think the precise cause
> is that to behave like an SMB3 server, the model involves opening a TCP
> connection, doing auth over that, then negotiating whether or not RDMA
> connections are possible, then opening the RDMA connections.  On our
> end, once the auth happens, smbd forks and the new user process handles
> the connection from that point on (which is integral to smbd's security
> model).  Because of this, and because the client initiates the RDMA
> connection and will only use a single well known port to connect to,
> incoming RDMA connections after negotiation would always go to the
> master smbd process and not the forked client authed smbd process.
> Because we don't have a way of then handing the RDMA connection from one
> process to another forked process, the model breaks down.  Possible
> solutions are:

It is interesting to think about the work Long Li did - which shows that
at least on the client side the model doesn't require opening a TCP
connection and doing auth on it before negotiating RDMA.

His smb3 kernel code allows trying SMB3 over RDMA immediately (without first
negotiating whether RDMA is allowed) - obviously finishing multichannel support
in cifs.ko is important, but I was surprised at first that it was
possible to use
RDMA for SMB3 without multichannel.


-- 
Thanks,

Steve