lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251028095450.GA38488@j66a10360.sqa.eu95>
Date: Tue, 28 Oct 2025 17:54:50 +0800
From: "D. Wythe" <alibuda@...ux.alibaba.com    >
To: Leon Romanovsky <leon@...nel.org>
Cc: "D. Wythe" <alibuda@...ux.alibaba.com>, mjambigi@...ux.ibm.com,
	wenjia@...ux.ibm.com, wintera@...ux.ibm.com,
	dust.li@...ux.alibaba.com, tonylu@...ux.alibaba.com,
	guwen@...ux.alibaba.com, kuba@...nel.org, davem@...emloft.net,
	netdev@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-rdma@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com,
	sidraya@...ux.ibm.com, jaka@...ux.ibm.com
Subject: Re: [PATCH net-next v2] net/smc: add full IPv6 support for SMC

On Mon, Oct 27, 2025 at 03:42:27PM +0200, Leon Romanovsky wrote:
> On Wed, Oct 22, 2025 at 11:23:09AM +0800, D. Wythe wrote:
> > The current SMC implementation is IPv4-centric. While it contains a
> > workaround for IPv4-mapped IPv6 addresses, it lacks a functional path
> > for native IPv6, preventing its use in modern dual-stack or IPv6-only
> > networks.
> > 
> > This patch introduces full, native IPv6 support by refactoring the
> > address handling mechanism to be IP-version agnostic, which is
> > achieved by:
> > 
> > - Introducing a generic `struct smc_ipaddr` to abstract IP addresses.
> > - Implementing an IPv6-specific route lookup function.
> > - Extend GID matching logic for both IPv4 and IPv6 addresses
> > 
> > With these changes, SMC can now discover RDMA devices and establish
> > connections over both native IPv4 and IPv6 networks.
> 
> Why can't you use rdma-cm in-kernel API like any other in-kernel RDMA consumers?
> 
> Thanks
> 
> >

Hi Leon,

Regarding RDMA-CM, I’m not sure if I’ve fully grasped your point, but
based on my current understanding, I believe SMC cannot use RDMA-CM.
There are a few reasons for this:

Firstly, SMC is designed to work not only with RDMA devices but also
needs to negotiate with DIBS(DIRECT INTERNAL BUFFER SHARING) devices. This
means we must support scenarios where no RDMA device is present.
Therefore, we require a round of out-of-band negotiation regardless of
the final device choice. In this context, even if we ultimately select
an RDMA device, using rdma-cm to establish the connection would be
redundant.

Additionally, SMC requires multiplexing multiple connections over a
single QP. We need to decide during the out-of-band negotiation which
specific QP to reuse for the connection. From what I know, rdma-cm does
not seem to offer this capability either.

Best regards,
D. Wythe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ