public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matthieu.baerts@tessares.net>
To: libc-alpha@sourceware.org
Subject: socket: add support for MPTCP socket option from the Linux kernel?
Date: Mon, 10 Oct 2022 15:37:03 +0200	[thread overview]
Message-ID: <4c818ddb-4d5f-29e8-18a3-817fa78fa9fc@tessares.net> (raw)

Hello,

Thank you for maintaining and continuing to add new features to glibc!


TL;DR: would it make sense to have a <netinet/mptcp.h> file?


I'm contributing to MPTCP in the Linux kernel. MPTCP is an extension to
TCP. The goal is to exchange data for a single connection over different
paths, simultaneously (or not). Its support in the Linux kernel has
started in Linux v5.6.

For the userspace, the usage is similar to TCP. The main difference is
visible when creating the socket because the MPTCP protocol has to be set:

  socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);

After that, the application uses the socket like it would do if it was
TCP. It can also get and set socket options from different levels:
socket, IP(v6), TCP and also a new one: SOL_MPTCP.

"IPPROTO_MPTCP" and "SOL_MPTCP" have been defined in glibc by Joseph
Myers, thank you for that!


With the MPTCP community, we were wondering if we can/should propose to
add MPTCP headers to help userspace apps supporting MPTCP specific
socket options. In other words, having something similar to
<netinet/tcp.h> but for MPTCP.

MPTCP in Linux exposes different structures, enum and macros to userspace:

 https://elixir.bootlin.com/linux/v6.0/source/include/uapi/linux/mptcp.h

Most of the "linux/mptcp.h" content is linked to different Netlink API
and we suppose this should not be exposed by glibc as well. The MPTCP
socket options might be interesting to expose as it is similar to TCP.
For the moment, there are 3 MPTCP specific socket options, defined at
the end of the mptcp.h file. They are all linked somehow to MPTCP_INFO,
similar to TCP_INFO.

When looking at the history of "sysdeps/gnu/netinet/tcp.h" file in
glibc, it looks like TCP specific socket options are up to date. But
that's not the case for the tcp_info structure for example which has not
been updated since 2007 apparently.


Considering the different elements mentioned above:

- Would it make sense to add a new "netinet/mptcp.h" file defining the
different MPTCP specific socket options and linked structures?

- Or is the new "policy" to ask userspace app developers to include
"linux/mptcp.h" from a recent enough kernel instead?

- If it makes sense to add a new "netinet/mptcp.h" file, how should we
handle conflicts between this new file and "linux/mptcp.h"? By using
__USE_MISC?


Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

             reply	other threads:[~2022-10-10 13:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 13:37 Matthieu Baerts [this message]
2022-10-21 14:05 ` Adhemerval Zanella Netto

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=4c818ddb-4d5f-29e8-18a3-817fa78fa9fc@tessares.net \
    --to=matthieu.baerts@tessares.net \
    --cc=libc-alpha@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).