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>
>
>
>
next prev 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