Re: [PATCH] libnvme: add mptcp trtype

[Geliang Tang <geliang@kernel.org>]

Hi Hannes,

On Thu, 2025-11-27 at 08:57 +0100, Hannes Reinecke wrote:
> On 11/27/25 02:26, Geliang Tang wrote:
> > A new NVMe target transport type NVMF_TRTYPE_MPTCP is defined for
> > MPTCP in
> > the kernel. Add it to libnvme as well.
> > 
> > Cc: Hannes Reinecke <hare@suse.de>
> > Signed-off-by: Geliang Tang <geliang@kernel.org>
> > ---
> >   src/nvme/fabrics.c | 1 +
> >   src/nvme/types.h   | 2 ++
> >   2 files changed, 3 insertions(+)
> > 
> > diff --git a/src/nvme/fabrics.c b/src/nvme/fabrics.c
> > index b0821e96..d3a1c033 100644
> > --- a/src/nvme/fabrics.c
> > +++ b/src/nvme/fabrics.c
> > @@ -73,6 +73,7 @@ const char * const trtypes[] = {
> >   	[NVMF_TRTYPE_RDMA]	= "rdma",
> >   	[NVMF_TRTYPE_FC]	= "fc",
> >   	[NVMF_TRTYPE_TCP]	= "tcp",
> > +	[NVMF_TRTYPE_MPTCP]	= "mptcp",
> >   	[NVMF_TRTYPE_LOOP]	= "loop",
> >   };
> >   
> > diff --git a/src/nvme/types.h b/src/nvme/types.h
> > index 4943e00f..2aa81938 100644
> > --- a/src/nvme/types.h
> > +++ b/src/nvme/types.h
> > @@ -6823,6 +6823,7 @@ struct nvmf_disc_log_entry {
> >    * @NVMF_TRTYPE_RDMA:		RDMA
> >    * @NVMF_TRTYPE_FC:		Fibre Channel
> >    * @NVMF_TRTYPE_TCP:		TCP
> > + * @NVMF_TRTYPE_MPTCP:		MPTCP
> >    * @NVMF_TRTYPE_LOOP:		Intra-host Transport (i.e.,
> > loopback), reserved
> >    *				for host usage.
> >    * @NVMF_TRTYPE_MAX:		Maximum value for &enum
> > nvmf_trtype
> > @@ -6832,6 +6833,7 @@ enum nvmf_trtype {
> >   	NVMF_TRTYPE_RDMA	= 1,
> >   	NVMF_TRTYPE_FC		= 2,
> >   	NVMF_TRTYPE_TCP		= 3,
> > +	NVMF_TRTYPE_MPTCP	= 4,
> >   	NVMF_TRTYPE_LOOP	= 254,
> >   	NVMF_TRTYPE_MAX,
> >   };
> 
> Sorry, you can't do that. You'll need to register a new protocol
> number
> from NVMexpress.org. And that would require a TPAR detailing out the
> mapping between NVMe commands and MPTCP frames.
> Which probably is a bit of an overhead.

Thank you for the reminder. May I ask where I can get the TPAR for NVMe
over TCP? I'd like to see what details need to be included to prepare
for future needs.

> Maybe it's easier to declare it as a TCP 'variant', keeping the
> protocol
> number and 'just' modify the TCP driver.

That does make things much simpler.

On the host side, it's easy. A new NVMF_OPT_MPTCP option can be added,
which can be set through nvme command as follows to create an MPTCP
socket:

    nvme discover -t tcp --mptcp -a 127.0.0.1 -s 4420
    nvme connect -t tcp --mptcp -a 127.0.0.1 -s 4420 -n
org.nvmexpress.mptcptest

On the target side, in v1 I sent you earlier, I reused TSAS (Transport
Specific Address Subtype) field for both MPTCP and TLS. However, that
approach made it impossible to use MPTCP and TLS simultaneously. Since
I'm currently working on TLS support for MPTCP, I believe MPTCP will
soon be capable of supporting TLS.

The approach I can think of to switch between TCP and MPTCP on the
target side is to introduce a Kconfig (e.g., NVME_TARGET_MPTCP). When
enabled, it would create MPTCP sockets instead of the standard TCP
ones. What are your thoughts? I'd appreciate your feedback.

Thanks,
-Geliang

> 
> Cheers,
> 
> Hannes