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

[Stefan (metze) Metzmacher]

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
additional
context into the kernel.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130903/aa450d1f/attachment.pgp>