Re: [PATCH v2 01/12] smb: smbdirect: add smbdirect_pdu.h with protocol definitions

[Stefan Metzmacher <metze@samba.org>]

Am 02.06.25 um 04:19 schrieb Namjae Jeon:
> On Mon, Jun 2, 2025 at 10:57 AM Steve French <smfrench@gmail.com> wrote:
>>
>>> Can you explain why he has split it into smbdirect_socket.h?
>>
>> The three header names seem plausible, but would be useful to have
>> Metze's clarification/explanation:
>> - the "protocol" related header info for smbdirect goes in
>> smb/common/smbdirect/smbdirect_pdu.h   (we use similar name smb2pdu.h
>> for the smb2/smb3 protocol related wire definitions)
>> - smbdirect.h for internal smbdirect structure definitions
>> - smbdirect_socket.h for things related to exporting it as a socket
>> (since one of the goals is to make smbdirect useable by Samba
>> userspace tools)
> There is no need to do things in advance that are not yet concrete and
> may change later.

The current idea is to merge transport_tcp and transport_rdma into
transport_sock, see
https://git.samba.org/?p=metze/linux/wip.git;a=blob;f=fs/smb/server/transport_sock.c;hb=66714b6c0fc1eacbeb5b85d07524caa722fc19cf

Which uses this interface:
https://git.samba.org/?p=metze/linux/wip.git;a=blob;f=fs/smb/common/smbdirect/smbdirect.h;hb=66714b6c0fc1eacbeb5b85d07524caa722fc19cf

But note that is just the direction were it goes, that current code has a lot of resolved merge conflicts,
which may not work at all currently.

Instead of putting my current code I try to take the existing client and server
code and merge it, so that we don't have a flag day commit that switches to
completely new code. Instead I try to do tiny steps in that direction
and may end with an interface that is similar but might be a bit different in
some parts.

> He can just put these changes in his own queue and work on them.
> I am pointing out why he is trying to put unfinished things in the public queue.

Because I want to base the next steps on something that is already accepted.

I really don't want to work on it for weeks and then some review will void
that work completely and I can start again.

> If You want to apply it, Please do it only on cifs.ko. When it is
> properly implemented, I want to apply it to ksmbd.

I can keep the ksmbd patches rebased on top and send them again
each time to get more feedback.

Would that work for you?

The key for me is discuss patches first and have them reviewed early
so that the following work rely on. Any the tiny steps should
make it possible to do easy review and make it possible to test each
tiny step.

metze