From nobody Thu May 2 22:55:59 2024 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a02:cbb9:0:0:0:0:0 with SMTP id v25csp1688540jap; Fri, 26 Nov 2021 02:35:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJzmsbRSuuXLI9brheLyeh+EpMzSGGuy3WgyWL5ymkTSzcmtpuSWp2aEEw82H5bYq9INk2he X-Received: by 2002:a65:560c:: with SMTP id l12mr20594603pgs.375.1637922958224; Fri, 26 Nov 2021 02:35:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637922958; cv=none; d=google.com; s=arc-20160816; b=y0gOI21nsFh5SjSnebDd9nT54zREJ6TiNmQTOYew7lYC8hKuB4ZcVUnhNSv4tdzu3i 7gXZy9wOlKEjS259L/yQsaOZrl2MY5ddw4pxhJTpFa76JszLJo4RLoSRLixWdGNEKN1Q yr4/zW/1kWGriWGjy/cUbGSm51A99qmeeckH/UPGp9e9KeK3s1WnLIGdNqN0fzG2JFs7 aef3aeXwAgn5jme0fik0cCclG8lzHgXaj+ifSY2HO06E4MUtJWJ8owHPhBDlD6arAou2 AGn3Bc0km3C/w6U45fy3U1hul9mtYr4SiFmlLSbIw6n0e2bo3LlkpBTAMEuEBbyhpK6p GbCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=vXBd28bcX264VU/S4G66DmxsLM80Ytxzh6lebwq/wHQ=; b=vzT29+xpDJ1oH6UT98Apqlwmd03E0gyDFchY0NMJ0aJld8Rd5Q5K2cBQKok+VPA4ZR wudFAMl8pLrQh66mujBBg/zFxs9nEWvHctVZ+zh1BRY/jv317GWoV5WsOdodyquriUbc sELi174bhQgsNq08TwA2REi6gN8lkI/cOTsD3MRXWxbVdmsAdL/3rLHMFc0CGQG2zoaT iQcHvmPkCfhrEZ+VFEWzdv6rcl/++p9/mp2N0tquQjZsIttOP2QVtewauhibLtuIjQlD kc5Yd/hGYc2+yHZA5JgO55WGp211qdAicqMMl8alBuAiDOz8Vdu+0Y1CQocGc2XE6apP Hraw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M8cgjrCx; spf=pass (google.com: domain of mptcp+bounces-2546-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1000:8100::1 as permitted sender) smtp.mailfrom="mptcp+bounces-2546-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sjc.edge.kernel.org (sjc.edge.kernel.org. [2604:1380:1000:8100::1]) by mx.google.com with ESMTPS id p2si6208702pgk.471.2021.11.26.02.35.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Nov 2021 02:35:58 -0800 (PST) Received-SPF: pass (google.com: domain of mptcp+bounces-2546-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1000:8100::1 as permitted sender) client-ip=2604:1380:1000:8100::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M8cgjrCx; spf=pass (google.com: domain of mptcp+bounces-2546-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1000:8100::1 as permitted sender) smtp.mailfrom="mptcp+bounces-2546-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sjc.edge.kernel.org (Postfix) with ESMTPS id 2B51A3E10F4 for ; Fri, 26 Nov 2021 10:35:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 083CC2C86; Fri, 26 Nov 2021 10:35:56 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B10168 for ; Fri, 26 Nov 2021 10:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637922953; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=vXBd28bcX264VU/S4G66DmxsLM80Ytxzh6lebwq/wHQ=; b=M8cgjrCxd0RbtQjpyQn2DUuZEplcxebIla/+q20pv5255zyFSme7w1yrODuvH3l978rLt6 t7WsUhZUwJFUvpZow0RYWjx1z0brGxSFzdFOk1g6oHbDrb12Lc+sjTvZsJOSuLu28NpgKy ZnA5DWIEemySjjB7fH4cUgBPAKatLMA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-130-tqsyYKIfOyyXxwuqk_2U4A-1; Fri, 26 Nov 2021 05:35:51 -0500 X-MC-Unique: tqsyYKIfOyyXxwuqk_2U4A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9164F801B17; Fri, 26 Nov 2021 10:35:50 +0000 (UTC) Received: from gerbillo.fritz.box (unknown [10.39.194.163]) by smtp.corp.redhat.com (Postfix) with ESMTP id B04061972E; Fri, 26 Nov 2021 10:35:49 +0000 (UTC) From: Paolo Abeni To: netdev@vger.kernel.org Cc: mptcp@lists.linux.dev Subject: [PATCH iproute2-next] mptcp: add support for fullmesh flag Date: Fri, 26 Nov 2021 11:35:44 +0100 Message-Id: <247b8dfb7254d4a1fb435b5efa756cea989b62cb.1637922870.git.pabeni@redhat.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Content-Type: text/plain; charset="utf-8" The link kernel supports this endpoint flag since v5.15, let's expose it to user-space. It allows creation on fullmesh topolgy via MPTCP subflow. Additionally update the related man-page, clarifying the behavior of related options. Acked-by: Mat Martineau Signed-off-by: Paolo Abeni --- ip/ipmptcp.c | 3 ++- man/man8/ip-mptcp.8 | 61 ++++++++++++++++++++++++++++++++++----------- 2 files changed, 49 insertions(+), 15 deletions(-) diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c index 0f5b6e2d..433fa68d 100644 --- a/ip/ipmptcp.c +++ b/ip/ipmptcp.c @@ -31,7 +31,7 @@ static void usage(void) " ip mptcp limits show\n" " ip mptcp monitor\n" "FLAG-LIST :=3D [ FLAG-LIST ] FLAG\n" - "FLAG :=3D [ signal | subflow | backup ]\n"); + "FLAG :=3D [ signal | subflow | backup | fullmesh ]\n"); =20 exit(-1); } @@ -53,6 +53,7 @@ static const struct { { "signal", MPTCP_PM_ADDR_FLAG_SIGNAL }, { "subflow", MPTCP_PM_ADDR_FLAG_SUBFLOW }, { "backup", MPTCP_PM_ADDR_FLAG_BACKUP }, + { "fullmesh", MPTCP_PM_ADDR_FLAG_FULLMESH }, }; =20 static void print_mptcp_addr_flags(unsigned int flags) diff --git a/man/man8/ip-mptcp.8 b/man/man8/ip-mptcp.8 index 22335b61..019debe2 100644 --- a/man/man8/ip-mptcp.8 +++ b/man/man8/ip-mptcp.8 @@ -53,6 +53,8 @@ ip-mptcp \- MPTCP path manager configuration .B subflow .RB "|" .B backup +.RB "|" +.B fullmesh .RB "]" =20 .ti -8 @@ -103,22 +105,41 @@ is a unique numeric identifier for the given endpoint =20 .TP .BR signal -the endpoint will be announced/signalled to each peer via an ADD_ADDR MPTCP -sub-option +The endpoint will be announced/signaled to each peer via an MPTCP ADD_ADDR +sub-option. Upon reception of an ADD_ADDR sub-option, the peer can try to +create additional subflows, see +.BR ADD_ADDR_ACCEPTED_NR. =20 .TP .BR subflow -if additional subflow creation is allowed by MPTCP limits, the endpoint wi= ll -be used as the source address to create an additional subflow after that -the MPTCP connection is established. +If additional subflow creation is allowed by the MPTCP limits, the MPTCP +path manager will try to create an additional subflow using this endpoint +as the source address after the MPTCP connection is established. =20 .TP .BR backup -the endpoint will be announced as a backup address, if this is a -.BR signal -endpoint, or the subflow will be created as a backup one if this is a +If this is a +.BR subflow +endpoint, the subflows created using this endpoint will have the backup +flag set during the connection process. This flag instructs the peer to +only send data on a given subflow when all non-backup subflows are +unavailable. This does not affect outgoing data, where subflow priority +is determined by the backup/non-backup flag received from the peer + +.TP +.BR fullmesh +If this is a +.BR subflow +endpoint and additional subflow creation is allowed by the MPTCP limits, +the MPTCP path manager will try to create an additional subflow for each +known peer address, using this endpoint as the source address. This will +occur after the MPTCP connection is established. If the peer did not +announce any additional addresses using the MPTCP ADD_ADDR sub-option, +this will behave the same as a plain .BR subflow -endpoint +endpoint. When the peer does announce addresses, each received ADD_ADDR +sub-option will trigger creation of an additional subflow to generate a +full mesh topology. =20 .sp .PP @@ -136,17 +157,29 @@ ip mptcp limits set change the MPTCP subflow creation= limits .IR SUBFLOW_NR specifies the maximum number of additional subflows allowed for each MPTCP connection. Additional subflows can be created due to: incoming accepted -ADD_ADDR option, local +ADD_ADDR sub-option, local .BR subflow endpoints, additional subflows started by the peer. =20 .TP .IR ADD_ADDR_ACCEPTED_NR -specifies the maximum number of ADD_ADDR suboptions accepted for each MPTCP -connection. The MPTCP path manager will try to create a new subflow for -each accepted ADD_ADDR option, respecting the +specifies the maximum number of incoming ADD_ADDR sub-options accepted for +each MPTCP connection. After receiving the specified number of ADD_ADDR +sub-options, any other incoming one will be ignored for the MPTCP connecti= on +lifetime. When an ADD_ADDR sub-option is accepted and there are no local +.IR fullmesh +endpoints, the MPTCP path manager will try to create a new subflow using t= he +address in the ADD_ADDR sub-option as the destination address and a source +address determined using local routing resolution +When +.IR fullmesh +endpoints are available, the MPTCP path manager will try to create new sub= flows +using each +.IR fullmesh +endpoint as a source address and the peer's ADD_ADDR address as the destin= ation. +In both cases the .IR SUBFLOW_NR -limit. +limit is enforced. =20 .sp .PP --=20 2.33.1