Yeah, another thing where I never understood why it was in the kernel.

The above text says that the aim is to do RDMA, to let the NIC access memory directly, but I'd think that existing Linux zero-copy interfaces would be sufficient for that.

https://en.wikipedia.org/wiki/Zero-copy

The Linux kernel supports zero-copy through various system calls, such as:

• sendfile, sendfile64;[9]
• splice;[10]
• tee;[11]
• vmsplice;[12]
• process_vm_readv;[13]
• process_vm_writev;[14]
• copy_file_range;[15]
• raw sockets with packet mmap[16] or AF_XDP.

So I'd think that the target workload has to be one where you can't just fetch a big chunk of pre-existing data, where you have to interject server-generated data in response to small requests, and even the overhead of switching to userspace to generate some kind of server-generated response is too high.

Which seems like a heck of a niche case.

But it obviously got approval from the kernel team.

googles

https://www.kernel.org/doc/html/next/filesystems/smb/ksmbd.html

The subset of performance related operations belong in kernelspace and the other subset which belong to operations which are not really related with performance in userspace. So, DCE/RPC management that has historically resulted into number of buffer overflow issues and dangerous security bugs and user account management are implemented in user space as ksmbd.mountd. File operations that are related with performance (open/read/write/close etc.) in kernel space (ksmbd). This also allows for easier integration with VFS interface for all file operations.

I guess you could accelerate open and close too.

In all seriousness, I feel like if you're in such a niche situation that you can't afford the overhead of going to userspace for that, (a) there's likely room to optimize your application to request different things and (b) CIFS might not be the best option to be sharing data over the network either.