All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tue, 3 Feb 2026 18:58:44 +0200	[thread overview]
Message-ID: <20260203165844.GX34749@unreal> (raw)
In-Reply-To: <1f77a9a6-9020-4d65-a6b9-fe68d4f6e46f@samba.org>

On Tue, Feb 03, 2026 at 04:25:35PM +0100, Stefan Metzmacher wrote:
> Am 28.01.26 um 15:11 schrieb Leon Romanovsky:
> > 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.
> 
> Thanks!
> 
> > Do you want me to take it through RDMA
> > tree?
> 
> As I also have other smb patches on top changing/using
> it I guess it would be easier if Steve would take them.
> 
> Steve, Leon what do you think?

I'm ok with that, let's me add my Acked-by on first patch.

Thanks

> 
> Thanks!
> metze

  reply	other threads:[~2026-02-03 16:58 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 ` [RFC PATCH 0/3] RDMA/smbdirect: introduce and use rdma_restrict_node_type() Leon Romanovsky
2026-02-03 15:25   ` Stefan Metzmacher
2026-02-03 16:58     ` Leon Romanovsky [this message]
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=20260203165844.GX34749@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.