Re: Work in progress SMB-Direct driver for the linux kernel

On Sun, Feb 4, 2018 at 10:39 AM, Doug Ledford [off-list ref] wrote:

On Thu, 2018-02-01 at 10:52 -0700, Jason Gunthorpe wrote:

quoted

On Thu, Feb 01, 2018 at 09:18:10AM +0100, Stefan Metzmacher wrote:

quoted

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