Hi Jason, >>> 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? > > If I had to guess it would be because Samba currently uses a fork > model ... it might be years before it gets to a completely threaded > model. Yes, and it also means that our client and server code only need minimal changes in order to work in the same way it would work over tcp. Only the RDMA read and writes need some more work, but I have some ideas where the userspace gives the kernel an fd, offset and length plus a remove memory descriptor as ioctl on the connection fd. Then the kernel can get the content from the filesystem and directly pass it to the rdma adapter, avoiding the copy from kernel to userspace and back. From userspace we'll just wait in the syscall and don't have to care about memory registrations and all other complex stuff. It also happens that smbd sometimes blocks in syscalls like unlink for a long time. It's good to have the kernel as 2nd entity that takes care of keepalives. metze
Attachment:
signature.asc
Description: OpenPGP digital signature
