SMB Direct Implementation via Linux Device Driver for Samba Design Doc, final?

Stefan (metze) Metzmacher metze at
Tue Sep 3 11:08:13 CEST 2013

Hi Or,

>>> >Another approach would be to have a single process responsible for all RDMA
>>> >handling and have the smbd's communicate with that process about new incoming
>>> >connections and reads and writes. While this would work, and could eliminate
>>> >multiple copies of the data with shared memory, it would involve a context
>>> >switch for most if not all RDMA transfers.
>> Only reason for doing this would be research how the protocol works...
> Yes, this is possible too. AFAIK, there another cluster file system rdma
> implementation which uses
> this practice, of daemon process  which handle RDMA and uses
> shared-memory with other processes.

Yes, a SMB-Direct deamon would also work, it could use a similar protocol as
a kernel module, so that we could easily switch between backends.

> In that respect, I am not sure to follow your comment on "could
> eliminate multiple copies of the data with shared
> memory" as I understood the design document you have sent, the intention
> is to allocate memory in the kernel
> rdma char-device which will be
> 1) used for send/recv/rdma
> 2) mmap-ed to user space
> So where are the copies in this design?
> As for "involve a contextswitch for most if not all RDMA transfers",
> indeed, in this architecture you
> will have contextswitch between the rdma daemon to the worker processes
> vs. user/kernel mode switch
> when you have each worker opening the rdma char-device.

But I guess each context switch to the deamon will include at least one
context into the kernel.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the samba-technical mailing list