From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id BE2973856DC0 for ; Fri, 21 Oct 2022 14:05:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE2973856DC0 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x331.google.com with SMTP id cb2-20020a056830618200b00661b6e5dcd8so1855898otb.8 for ; Fri, 21 Oct 2022 07:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jzRhnkUVh/vmOf+7160dlr7zhKWAnMA9PdN3lwsxSw4=; b=H6sR1jJmzeGwcZtj0yd1S5Nb3+UnLtPhyhQIX+2P30iiT5wD318CjLVH1UawLy4Bhl nr816dueILos3ZVcQEOFmx5EgNqP2N8GEE7L+NScpFb7R2JdsL8DVtYBDAfVu0RU1FgZ 0+iaNReaoPAjEoFDWa+i4LbyfihzMulajuwX556HyDN6elNEPh+kMRLaFDxqfHvAZwWw tcEPRCu4olZZ9PIcqS6udr89IT8O3PM+u7qiN0KNredG7Zr88Fstv7/Q1qfVyoR4pxJr dvBr7ZqfibVXbZ7Ao1lmwN8AEBCmrDExUiUjSqbEyZfwuHQgfjwo1mF9sq9bQ22xrVZL p1Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jzRhnkUVh/vmOf+7160dlr7zhKWAnMA9PdN3lwsxSw4=; b=C7+E/rhPhjqyt0aTR5SWqpw1vCQmx4k9GIC1tnXjipMS7dw+P8eEmFsBPgYTjKjPUw lK/CxV9CBmQecsMcp4Ra1oYJoQhB7HJ8gEYzTA8Nv6EiCl4XLG5bU/aUWwwhID5rcvyi nIDeSngNTddpvEAIq3zNiz6xoaUPNyGIc5vmYWJe6qeOiyOK31ITyUk56u6YvnULb5u/ IbGDsAfVfgsHXk558jF27pdUi7Cg/Vay27SXgjr+fjQVpk4tcmXbuaaUQeiZ05276Mvo r0S/U5TD2QKM47/dCrjXzoJja+d4AEEIh9cnfpw/zfGLmeIFD68wUrbnjPVOmcP2mNk0 95Ww== X-Gm-Message-State: ACrzQf0/j4pAWyD981ghXWZlyTfLvHmkIWy8u4jAwWooSOfg19+EpwgP vPrQoEYu/yuJz6UH8Z0lTmZ9dg== X-Google-Smtp-Source: AMsMyM7sMlDUvDYA9sYk1/eZlLT4cXLTHXmZEwPzhi9eCVA+RQzRwVTirQb2DypsK5RLnsMSYXZGAA== X-Received: by 2002:a9d:64c3:0:b0:656:d706:1df with SMTP id n3-20020a9d64c3000000b00656d70601dfmr9552862otl.212.1666361145284; Fri, 21 Oct 2022 07:05:45 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:7d19:5909:4ed0:fbc6:5cfd? ([2804:1b3:a7c3:7d19:5909:4ed0:fbc6:5cfd]) by smtp.gmail.com with ESMTPSA id n32-20020a056870242000b0012796e8033dsm10186533oap.57.2022.10.21.07.05.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Oct 2022 07:05:44 -0700 (PDT) Message-ID: Date: Fri, 21 Oct 2022 11:05:42 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: socket: add support for MPTCP socket option from the Linux kernel? Content-Language: en-US To: Matthieu Baerts , libc-alpha@sourceware.org References: <4c818ddb-4d5f-29e8-18a3-817fa78fa9fc@tessares.net> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <4c818ddb-4d5f-29e8-18a3-817fa78fa9fc@tessares.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: On 10/10/22 10:37, Matthieu Baerts via Libc-alpha wrote: > 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? It is a matter to maintainability, since any new header in glibc that is bounded to a kernel specific features will need to be updated on every release if there is any new definitions. We already have Linux specific definition on sysdeps/unix/sysv/linux/netinet, so I think it should be feasible to add a Linux specific MPTCP header. Besides it seems no to be a Linux specific features, it also seems that no other system does provide such header though (at least none I check, FreeBSD 13, MacOSX 12, Solaris 11, AIX 7.2). > > - Or is the new "policy" to ask userspace app developers to include > "linux/mptcp.h" from a recent enough kernel instead? I still think this is not a settle topic, although with recent syscall support we do tend to include kernel headers to get the latest definition. It comes with its own burden, since the header might not be available and dependant on the glibc header we need to add extra handling. Usually on distro, the kernel headers seems to be update more often than glibc; so a glibc header might not be updated with the latest kernel definitions. I do not follow MCTCP development on Linux kernel, but if it is actively developed and newer features added in each release, I would say it would be better to keep as a linux header so users know exactly what kind of features the underlying kernel supports. > > - 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? That is not straightforward, depends of the feature you want to support, and adds extra maintainability (and it is why I am not personally found on including kernel headers in glibc exported headers). For instance for RSEQ (sysdeps/unix/sysv/linux/sys/rseq.h: #ifdef __has_include # if __has_include ("linux/rseq.h") # define __GLIBC_HAVE_KERNEL_RSEQ # endif #else # include # if LINUX_VERSION_CODE >= KERNEL_VERSION (4, 18, 0) # define __GLIBC_HAVE_KERNEL_RSEQ # endif #endif #ifdef __GLIBC_HAVE_KERNEL_RSEQ /* We use the structures declarations from the kernel headers. */ # include #else /* __GLIBC_HAVE_KERNEL_RSEQ */ /* We use a copy of the include/uapi/linux/rseq.h kernel header. */ [...] #endif And this is similar to close_range flags (sysdeps/unix/sysv/linux/bits/unistd_ext.h): #ifdef __has_include # if __has_include ("linux/close_range.h") # include "linux/close_range.h" # endif #endif /* Unshare the file descriptor table before closing file descriptors. */ #ifndef CLOSE_RANGE_UNSHARE # define CLOSE_RANGE_UNSHARE (1U << 1) #endif /* Set the FD_CLOEXEC bit instead of closing the file descriptor. */ #ifndef CLOSE_RANGE_CLOEXEC # define CLOSE_RANGE_CLOEXEC (1U << 2) #endif Since glibc can be built with kernel headers old as 3.2, you will need to provide expected kernel flags and structures as a fallback if the kernel header can nto be included. Since this is Linux specific header, there is no direct use of __USE_MISC (which is used to adapt the definition to standard headers).