MPTCP Linux Development
 help / color / mirror / Atom feed
From: Mat Martineau <martineau@kernel.org>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next RFC] mptcp: socket option to check for fallback
Date: Mon, 6 May 2024 18:09:10 -0700 (PDT)	[thread overview]
Message-ID: <764b2d9f-8600-a3fd-9312-64b43e78162f@kernel.org> (raw)
In-Reply-To: <20240506-getsockopt-tcp_is_mptcp-v1-1-4f044660f7c3@kernel.org>

On Mon, 6 May 2024, Matthieu Baerts (NGI0) wrote:

> A way for an application to know if the connection fell back to TCP is
> to use getsockopt(MPTCP_INFO) and look for errors. The issue with this
> technique is that the same errors -- EOPNOTSUPP (IPv4) and ENOPROTOOPT
> (IPv6) -- are returned if there was a fallback, or if the kernel doesn't
> support this socket option. The userspace then has to look at the kernel
> version to know what to expect.
>
> It is not clean, and it doesn't take into account older kernels where
> the socket option has been backported. A cleaner way would be to expose
> this info to the TCP socket level. In case of MPTCP socket where no
> fallback happened, the socket options for the TCP level will be handled
> in MPTCP code, in mptcp_getsockopt_sol_tcp(). If not, that will be in
> TCP code, in do_tcp_getsockopt(). So one simply has to return 1, while
> the other can return 0.
>
> If the socket option is not supported, an error will be reported:
> EOPNOTSUPP (95 - Operation not supported) for MPTCP sockets, ENOPROTOOPT
> (92 - Protocol not available) for TCP sockets.
>

Hi Matthieu -

I like this approach as it's much simpler to check than MPTCP_INFO, and 
gives a clear answer to both "Is this kernel new enough to tell me the 
fallback status?" and "If it is new enough, is it currently a TCP or MPTCP 
socket?".

- Mat

> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> ---
> Notes:
>  - This is linked to a discussion we had at the last meeting: having a
>    cleaner way, not having to check the kernel version. But maybe it is
>    fine to look at the kernel version? I mean: 5.16 is quite old now,
>    maybe too late for that kind of patch?
>  - During these discussions, I thought we had to also look at the
>    mptcpi_flags field from the 'struct mptcp_info', and check if
>    MPTCP_INFO_FLAG_FALLBACK was set: that's not needed, and this
>    simplify a bit what needs to be done to check for a fallback:
>    https://github.com/multipath-tcp/mptcp.dev/pull/6
>  - Maybe it is enough to optimise the getsockopt(MPTCP_INFO) like this?
>    https://lore.kernel.org/mptcp/20240418-mptcp-getsockopt-info-opti-v1-1-7138a96eb50c@kernel.org/
>
>    Note: typically, it is not possible to do a getsockopt() with an
>    optlen of size 0 from higher level lib (Python, Go, Rust, etc.).
>    Maybe we would need a similar optimisation for optlen <= 4?
> ---
> include/uapi/linux/tcp.h | 2 ++
> net/ipv4/tcp.c           | 3 +++
> net/mptcp/sockopt.c      | 2 ++
> 3 files changed, 7 insertions(+)
>
> diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
> index c07e9f90c084..dbf896f3146c 100644
> --- a/include/uapi/linux/tcp.h
> +++ b/include/uapi/linux/tcp.h
> @@ -135,6 +135,8 @@ enum {
> #define TCP_AO_GET_KEYS		41	/* List MKT(s) */
> #define TCP_AO_REPAIR		42	/* Get/Set SNEs and ISNs */
>
> +#define TCP_IS_MPTCP		43	/* Is MPTCP being used? */
> +
> #define TCP_REPAIR_ON		1
> #define TCP_REPAIR_OFF		0
> #define TCP_REPAIR_OFF_NO_WP	-1	/* Turn off without window probes */
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 95ca73937a1c..39ee5a107544 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -4363,6 +4363,9 @@ int do_tcp_getsockopt(struct sock *sk, int level,
>
> 		return err;
> 	}
> +	case TCP_IS_MPTCP:
> +		val = 0;
> +		break;
> 	default:
> 		return -ENOPROTOOPT;
> 	}
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index 2edaf1a16005..e50262b8942e 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -1354,6 +1354,8 @@ static int mptcp_getsockopt_sol_tcp(struct mptcp_sock *msk, int optname,
> 		return mptcp_put_int_option(msk, optval, optlen, msk->nodelay);
> 	case TCP_NOTSENT_LOWAT:
> 		return mptcp_put_int_option(msk, optval, optlen, msk->notsent_lowat);
> +	case TCP_IS_MPTCP:
> +		return mptcp_put_int_option(msk, optval, optlen, 1);
> 	}
> 	return -EOPNOTSUPP;
> }
>
> ---
> base-commit: f16f6f211e692c812d4d5b24e8eff95188ecb62c
> change-id: 20240506-getsockopt-tcp_is_mptcp-735fec263981
>
> Best regards,
> -- 
> Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
>
>

  parent reply	other threads:[~2024-05-07  1:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-06 13:15 [PATCH mptcp-next RFC] mptcp: socket option to check for fallback Matthieu Baerts (NGI0)
2024-05-06 14:05 ` MPTCP CI
2024-05-07  1:09 ` Mat Martineau [this message]
2024-05-09 16:25   ` Matthieu Baerts

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=764b2d9f-8600-a3fd-9312-64b43e78162f@kernel.org \
    --to=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    /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