From: Leon Romanovsky <leon@kernel.org>
To: Stefan Metzmacher <metze@samba.org>
Cc: linux-rdma@vger.kernel.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, Jason Gunthorpe <jgg@ziepe.ca>,
Steve French <smfrench@gmail.com>, Tom Talpey <tom@talpey.com>,
Long Li <longli@microsoft.com>,
Namjae Jeon <linkinjeon@kernel.org>
Subject: Re: [RFC PATCH 0/3] RDMA/smbdirect: introduce and use rdma_restrict_node_type()
Date: Wed, 28 Jan 2026 16:11:23 +0200 [thread overview]
Message-ID: <20260128141123.GG40916@unreal> (raw)
In-Reply-To: <cover.1769025321.git.metze@samba.org>
On Wed, Jan 21, 2026 at 09:07:10PM +0100, Stefan Metzmacher wrote:
> Hi,
>
> for smbdirect it required to use different ports depending
> on the RDMA protocol. E.g. for iWarp 5445 is needed
> (as tcp port 445 already used by the raw tcp transport for SMB),
> while InfiniBand, RoCEv1 and RoCEv2 use port 445, as they
> use an independent port range (even for RoCEv2, which uses udp
> port 4791 itself).
>
> Currently ksmbd is not able to function correctly at
> all if the system has iWarp (RDMA_NODE_RNIC) interface(s)
> and any InfiniBand, RoCEv1 and/or RoCEv2 interface(s)
> at the same time.
>
> And cifs.ko uses 5445 with a fallback to 445, which
> means depending on the available interfaces, it tries
> 5445 in the RoCE range or may tries iWarp with 445
> as a fallback. This leads to strange error messages
> and strange network captures.
>
> To avoid these problems they will be able to
> use rdma_restrict_node_type(RDMA_NODE_RNIC) before
> trying port 5445 and rdma_restrict_node_type(RDMA_NODE_IB_CA)
> before trying port 445. It means we'll get early
> -ENODEV early from rdma_resolve_addr() without any
> network traffic and timeouts.
>
> This is marked as RFC as I want to get feedback
> if the rdma_restrict_node_type() function is acceptable
> for the RDMA layer. And because the current form of
> the smb patches are not tested, I only tested the
> rdma part with my branch the prepares IPPROTO_SMBDIRECT
> sockets.
>
> I'm not sure if this would be acceptable for 6.19
> in order to avoid the smb layer problems, if the
> RDMA layer change is only acceptable for 7.0 that's
> also fine.
>
> This is based on the following fix applied:
> smb: server: reset smb_direct_port = SMB_DIRECT_PORT_INFINIBAND on init
> https://lore.kernel.org/linux-cifs/20251208154919.934760-1-metze@samba.org/
> It's not yet in Linus' tree, so if this gets ready
> before it's merged we can squash it.
>
> Stefan Metzmacher (3):
> RDMA/core: introduce rdma_restrict_node_type()
> smb: client: make use of rdma_restrict_node_type()
> smb: server: make use of rdma_restrict_node_type()
The approach looks reasonable. Do you want me to take it through RDMA
tree?
Thanks
>
> drivers/infiniband/core/cma.c | 30 ++++++++
> drivers/infiniband/core/cma_priv.h | 1 +
> fs/smb/client/smbdirect.c | 26 +++++++
> fs/smb/server/transport_rdma.c | 108 +++++++++++++++++++++--------
> include/rdma/rdma_cm.h | 17 +++++
> 5 files changed, 154 insertions(+), 28 deletions(-)
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-01-28 14:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 20:07 [RFC PATCH 0/3] RDMA/smbdirect: introduce and use rdma_restrict_node_type() Stefan Metzmacher
2026-01-21 20:07 ` [RFC PATCH 1/3] RDMA/core: introduce rdma_restrict_node_type() Stefan Metzmacher
2026-02-03 16:59 ` Leon Romanovsky
2026-01-21 20:07 ` [RFC PATCH 2/3] smb: client: make use of rdma_restrict_node_type() Stefan Metzmacher
2026-01-21 20:07 ` [RFC PATCH 3/3] smb: server: " Stefan Metzmacher
2026-01-28 14:11 ` Leon Romanovsky [this message]
2026-02-03 15:25 ` [RFC PATCH 0/3] RDMA/smbdirect: introduce and use rdma_restrict_node_type() Stefan Metzmacher
2026-02-03 16:58 ` Leon Romanovsky
2026-02-03 17:37 ` Steve French
2026-02-03 20:16 ` Leon Romanovsky
2026-02-03 22:58 ` Namjae Jeon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260128141123.GG40916@unreal \
--to=leon@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=metze@samba.org \
--cc=samba-technical@lists.samba.org \
--cc=smfrench@gmail.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox