From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id BB1CC385E008 for ; Mon, 10 Oct 2022 13:37:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB1CC385E008 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=tessares.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tessares.net Received: by mail-wr1-x42a.google.com with SMTP id a3so17144929wrt.0 for ; Mon, 10 Oct 2022 06:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares.net; s=google; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=8Hs7Jc11hu9RgCZElOimxzezrgOc2P3GTBj6FoObW/8=; b=qLqovL2xPhoS7XzmCNV6IHZVkPHVkO5CO9sZV1MVbx0TAz+xYYkoHrmGRiYarUcJCz JnbOKrY+SsNAgH1UJmMVEgsP7g1qRJ9zUOT3o+4BQufo5idYMPjClg6Yyr5fMHN2db9+ uYrZXAEy4YPDcHF+me7e5PkiTSYOt79UalsqFm68dYPADHKUTDIYoYa+qnrLX1efrNOR ioHkn7EJ8W00DYigWKLCOJHLYY/33vA/ppVt6RFR5QUkNU3JSrX+3gA7fkw5NMwnkHwj nVrNBZVYkMSASd6TQ4NKxDirEOFvJK9v5dfiZVOWlSmZHROm9xoJtuhzImMGmvSu7I/r 2WMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=8Hs7Jc11hu9RgCZElOimxzezrgOc2P3GTBj6FoObW/8=; b=XvvbqktmPmg+XCJtM3A5aq4LHU7CX85PKSku7vidGqVWyCSDt+3RALrvkCmHe+9uRH U+QcjTCU3UF4byuNqRJpNcPHjGc9rGgodVfjS61IsZ9h2dvy/VWvG6B8ADOgiuXfXOT6 CAwser2uVULbL4rN1HHWAWuD1eIJeOesDJ5aC/eXIXfE6PJXvW/d91xIK5DoK/aSL+41 na1Saq7058CC+5UuwfIMgo/2DS+wqw/c16soiyUqnMKUUCpM364IAVrXnWpNORtpzxlK 8uDK6jqAyimo5qbj0u4ySHz3NS9MHcsKe8H/0lPXnn1fpf8faijekJqVyYec6BuihptI VAag== X-Gm-Message-State: ACrzQf3DOLjoBJqjEfjnRyUZbTtAVoR30U2MZlfTq5ebTe8nDd/W/4qW HiG+0LSAO+fjy4uYpj4Q2lvfv2FhkGYCSw== X-Google-Smtp-Source: AMsMyM6zXdbK/vQp2HP4H+AMuSCdk1Tz7hb22H/gANxlh+J00vPMNeU0YlnMbZBVd862r5gU5S3EQw== X-Received: by 2002:a5d:6683:0:b0:22c:dcc5:abb2 with SMTP id l3-20020a5d6683000000b0022cdcc5abb2mr11381200wru.85.1665409025538; Mon, 10 Oct 2022 06:37:05 -0700 (PDT) Received: from [10.44.2.26] ([81.246.10.41]) by smtp.gmail.com with ESMTPSA id c66-20020a1c3545000000b003bdb2c7f3d1sm16461656wma.32.2022.10.10.06.37.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 06:37:04 -0700 (PDT) Message-ID: <4c818ddb-4d5f-29e8-18a3-817fa78fa9fc@tessares.net> Date: Mon, 10 Oct 2022 15:37:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-GB To: libc-alpha@sourceware.org From: Matthieu Baerts Subject: socket: add support for MPTCP socket option from the Linux kernel? Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, Thank you for maintaining and continuing to add new features to glibc! TL;DR: would it make sense to have a 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 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