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

[Namjae Jeon]

On Tue, Jun 3, 2025 at 7:03 AM Stefan Metzmacher <metze at samba.org> wrote:
>
> Am 02.06.25 um 04:19 schrieb Namjae Jeon:
> > On Mon, Jun 2, 2025 at 10:57 AM Steve French <smfrench at 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
Hm.. I can not access these links.. Is it just me?
>
> 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.
Okay.

>
> > 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.
It was too tiny a step and unclear.
i.e. the patch description should not have comments like "It will be
used in the next commits..."
>
> > 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?
Okay, Please re-include the ksmbd patches in the next patch-set and I
will check them.
>
> 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.
Okay. I agreed. But It should not be too tiny.
As I said above, please don't send it in pieces that I can understand
by looking at the next commits.

Thanks.
>
> metze
>