This patch adds IPPROTO_SMBDIRECT and SOL_SMBDIRECT constants to the
networking subsystem. These definitions are essential for applications
to set socket options and protocol identifiers related to the SMBDIRECT
protocol, defined in [MS-SMBD] by Microsoft. It is used as wrapper
around RDMA in order to provide a transport for SMB3, but Microsoft also
uses it as transport for other protocols.

SMBDIRECT works over Infiniband, RoCE and iWarp.
RoCEv2 is based on IP/UDP and iWarp is based on IP/TCP,
so these use IP addresses natively.
Infiniband and RoCEv1 require IPOIB in order to be used for
SMBDIRECT.

So instead of adding a PF_SMBDIRECT, which would only use AF_INET[6],
we use IPPROTO_SMBDIRECT instead, this uses a number not
allocated from IANA, as it would not appear in an IP header.

This is similar to IPPROTO_SMC, IPPROTO_MPTCP and IPPROTO_QUIC,
which are linux specific values for the socket() syscall.

  socket(AF_INET, SOCK_STREAM, IPPROTO_SMBDIRECT);
  socket(AF_INET6, SOCK_STREAM, IPPROTO_SMBDIRECT);

This will allow the existing smbdirect code used by
cifs.ko and ksmbd.ko to be moved behind the socket layer [1],
so that there's less special handling. Only sock_sendmsg()
sock_recvmsg() are used, so that the main stream handling
is done all the same for tcp, smbdirect and later also quic.

The special RDMA read/write handling will be via direct
function calls as they are currently done for the in kernel
consumers.

As a start __sock_create(kern=0)/sk->sk_kern_sock == 0 will
still cause a -EPROTONOSUPPORT. So only in kernel consumers
will be supported for now.

Once I have developed a stable interface for the RDMA read/write
handling using sendmsg/recvmsg with MSG_OOB and msg_control,
it will also exposed to userspace in order to allow Samba to
use it.

[1]
https://git.samba.org/?p=metze/linux/wip.git;a=shortlog;h=refs/heads/master-ipproto-smbdirect

Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Steve French <smfrench@gmail.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Long Li <longli@microsoft.com>
Cc: Namjae Jeon <linkinjeon@kernel.org>
Cc: Xin Long <lucien.xin@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>

---

In order to avoid conflicts with the addition of IPPROTO_QUIC,
the patch is based on netdev-next/main + the patch adding
IPPROTO_QUIC and SOL_QUIC [2].

[2]
https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u

As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
in various userspace applications it would be good to have
this merged to netdev-next/main even if the actual
implementation is still waiting for review.

Having IPPROTO_SMBDIRECT+SOL_SMBDIRECT merged would also make
thinks easier for me.
---
 include/linux/socket.h  | 1 +
 include/uapi/linux/in.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index b4563ffe552b..350a579a87da 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -402,6 +402,7 @@ struct ucred {
 #define SOL_SMC		286
 #define SOL_VSOCK	287
 #define SOL_QUIC	288
+#define SOL_SMBDIRECT	289
 
 /* IPX options */
 #define IPX_TYPE	1
diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
index 34becd90d3a6..b30caa6db8ca 100644
--- a/include/uapi/linux/in.h
+++ b/include/uapi/linux/in.h
@@ -85,6 +85,8 @@ enum {
 #define IPPROTO_RAW		IPPROTO_RAW
   IPPROTO_SMC = 256,		/* Shared Memory Communications		*/
 #define IPPROTO_SMC		IPPROTO_SMC
+  IPPROTO_SMBDIRECT = 257,	/* RDMA based transport (mostly used by SMB3) */
+#define IPPROTO_SMBDIRECT	IPPROTO_SMBDIRECT
   IPPROTO_QUIC = 261,		/* A UDP-Based Multiplexed and Secure Transport	*/
 #define IPPROTO_QUIC		IPPROTO_QUIC
   IPPROTO_MPTCP = 262,		/* Multipath TCP connection		*/
-- 
2.43.0

On 11/26/25 12:14 PM, Stefan Metzmacher wrote:
> In order to avoid conflicts with the addition of IPPROTO_QUIC,
> the patch is based on netdev-next/main + the patch adding
> IPPROTO_QUIC and SOL_QUIC [2].
> 
> [2]
> https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u
> 
> As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
> in various userspace applications it would be good to have
> this merged to netdev-next/main even if the actual
> implementation is still waiting for review.

Let me start from here... Why exactly? such applications will not work
(or at least will not use IPPROTO_QUIC) without the actual protocol
implementation.

Build time issues are much more easily solved with the usual:

#ifndef IPPROTO_*
#define IPPROTO_
#endif

that the application code should still carry for a bit of time (until
all the build hosts kernel headers are updated).

The above considerations also apply to this patch. What is the net
benefit? Why something like the above preprocessor's macros are not enough?

We need at least to see the paired implementation to accept this patch,
and I personally think it would be better to let the IPPROTO definition
and the actual implementation land together.

Cheers,

Paolo

Hi Paolo,

> On 11/26/25 12:14 PM, Stefan Metzmacher wrote:
>> In order to avoid conflicts with the addition of IPPROTO_QUIC,
>> the patch is based on netdev-next/main + the patch adding
>> IPPROTO_QUIC and SOL_QUIC [2].
>>
>> [2]
>> https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u
>>
>> As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
>> in various userspace applications it would be good to have
>> this merged to netdev-next/main even if the actual
>> implementation is still waiting for review.
> 
> Let me start from here... Why exactly? such applications will not work
> (or at least will not use IPPROTO_QUIC) without the actual protocol
> implementation.

There's the out of tree quic driver, that is used by some people
see https://github.com/lxin/quic.

And Samba 4.23 already uses the specific *_QUIC values,
so it would be good to make sure the values are not used for
something else, by accident.

> Build time issues are much more easily solved with the usual:
> 
> #ifndef IPPROTO_*
> #define IPPROTO_
> #endif

Sure, but that still only works reliable if the constants
don't change.

> that the application code should still carry for a bit of time (until
> all the build hosts kernel headers are updated).

The build hosts often don't have current kernel headers
anyway, that's why applications have the hard coded (at least fallback values).

But a host might have a newer kernel (or out of tree module)
at runtime, which would allow the application to use the feature.

> The above considerations also apply to this patch. What is the net
> benefit? Why something like the above preprocessor's macros are not enough?

It's mainly to have the constants reserved in order to avoid collisions
at runtime.

And in the current case also the merge conflict between the two patchsets,
that's another why I thought it would be good to the _QUIC patch already
accepted.

> We need at least to see the paired implementation to accept this patch,

I hope to post the first part of the _SMBDIRECT socket code next
week, it's already working for the in kernel users cifs.ko and ksmbd.ko,
but I want to split the relatively large commit into smaller chunks,
for better review, the current state consists of the top 3 commits of
https://git.samba.org/?p=metze/linux/wip.git;a=shortlog;h=refs/heads/master-ipproto-smbdirect-v0.5
1. the addition of the socket layer above the existing code, for in kernel use only
2. change cifs.ko to use it
3. change ksmbd.ko to use it.

Opening it for userspace will be developed in the next weeks.

 > and I personally think it would be better to let the IPPROTO definition
 > and the actual implementation land together.

In general I'd agree with you, I'm fine with deferring this patch
a bit and will cope if the _QUIC patch is also deferred.

Anyway thanks for the feedback!
metze