From nobody Thu Apr 25 20:41:06 2024 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a02:cbb9:0:0:0:0:0 with SMTP id v25csp397504jap; Thu, 18 Nov 2021 04:31:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpH8fdE9LoOKb+Bb7JmY0hgtIBpcVFZZ1OhQNkTy4fvnmmjd/LLGrKi2MGhqBcaP5kOClM X-Received: by 2002:a05:622a:18e:: with SMTP id s14mr26756094qtw.203.1637238701942; Thu, 18 Nov 2021 04:31:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637238701; cv=none; d=google.com; s=arc-20160816; b=UuRalXMaElRHx2NLdLTYTJ9IQ9QEi7NtVXjQ/6vRUhI7ZormLeKj1E9ZQisRStnPxr oSskR8Sp/wETBivNa3z/VVO60k19288nyfRkkpCVnfwRQQEuj9DeSg3f5DeEBrQ6c0+T 9aZ/2hfFaE0ADkMjK6Dg4L5BUNBX59a+c6qScy+vZQl7/smAPfCGW35KFOeqpRpLM1DP 4tR6+jevKr98pwspkh1OBWHlIkOTbuqA1C28fJsjqwtwT4xS9PYOHSOQVH9qhctesubq Ap4kYzD/frFTpfYOq8/oAM+KTfSYZrWBbYqvhrmM9jiQPoP/1REj+sQE23E0OEaMQ/y+ WtdQ== 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:to:from :dkim-signature; bh=6w3oL6uqLGyeAGEohe6FtRqd8YJ/NkldKwZz64ohDHk=; b=ezQA5IJMm/wJ3FL4GHLKVXVy8WdLDvD5VQyQ165XJ/n4kxDXgzGFcWCy51Ut6R54ou 3S1LC3oXnCyxjokPWge3jsHxAQtCh6gR8Q0XaPJludsLKARCn6CBAFEPJWaDEFn/z7BN D8Z+Xp1SJ9jL7DQbxf+cgC4dpxSRQskSKWCKy4t5Q+kSzvwGEne4l3b5W5z+GVM8WGqD WdTE8dA9tjTIyiwotDk7QwVP4qSLY0L5Hj+NxxQ2mXQoW0NDqvZivVw5A6fD14F9jutV IZLMd/gzQhuJFUeTEdjMlXkdAWKePG+2LKZUBG3rD36KFX97oW8ZEIUATI3eazzOtfk9 I9uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ca8SaIbO; spf=pass (google.com: domain of mptcp+bounces-2465-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1:3600::1 as permitted sender) smtp.mailfrom="mptcp+bounces-2465-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from ewr.edge.kernel.org (ewr.edge.kernel.org. [2604:1380:1:3600::1]) by mx.google.com with ESMTPS id a11si6510994vsl.428.2021.11.18.04.31.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Nov 2021 04:31:41 -0800 (PST) Received-SPF: pass (google.com: domain of mptcp+bounces-2465-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1:3600::1 as permitted sender) client-ip=2604:1380:1:3600::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ca8SaIbO; spf=pass (google.com: domain of mptcp+bounces-2465-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 2604:1380:1:3600::1 as permitted sender) smtp.mailfrom="mptcp+bounces-2465-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 ewr.edge.kernel.org (Postfix) with ESMTPS id ABD631C09F1 for ; Thu, 18 Nov 2021 12:31:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3BDD472; Thu, 18 Nov 2021 12:31:39 +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 61D8B68 for ; Thu, 18 Nov 2021 12:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637238696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6w3oL6uqLGyeAGEohe6FtRqd8YJ/NkldKwZz64ohDHk=; b=ca8SaIbOOF5UAXfTdGsB+lSbydaCEYM/GTjx7T5RbU9spJlXfscq1i2W3BovxtS7Osnlyp 3rtX/waHcR886y7bzw2jug5VRRLrwzDjseezDbmFUP4+JrhGYpTYssEs6Z2JFXl1CODspS kSjhbRjf0czQatwV3GJJACGEnihjgbM= 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-336-_xh_oI2LMpaZwkMDmbFWpg-1; Thu, 18 Nov 2021 07:31:35 -0500 X-MC-Unique: _xh_oI2LMpaZwkMDmbFWpg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3029310168F4 for ; Thu, 18 Nov 2021 12:31:34 +0000 (UTC) Received: from gerbillo.fritz.box (unknown [10.39.194.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D982608BA for ; Thu, 18 Nov 2021 12:31:33 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH iproute2-next] mptcp: add support for fullmesh flag Date: Thu, 18 Nov 2021 13:31:15 +0100 Message-Id: Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pabeni@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable 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. Signed-off-by: Paolo Abeni --- notes: - currently sent only to mptcp ML, looking for "editorial" reviews :) - as a side doc-update effect, this could possibly close issue/237 --- ip/ipmptcp.c | 3 ++- man/man8/ip-mptcp.8 | 47 ++++++++++++++++++++++++++++++++++----------- 2 files changed, 38 insertions(+), 12 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..367ecc64 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,36 @@ 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 ADD_ADDR MPTCP +sub-option. Upon reception of an ADD_ADDR option, the peer can try to crea= te +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 MPTCP limits, after that the +MPTCP connection is established, the MPTCP path manager will try to create +an additional subflow using this endpoint as the source address. =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 be backup ones. +Backup subflows are used only when all non-backup subflows are unavailable. + +.TP +.BR fullmesh +if this is a +.BR subflow +endpoint, if additional subflow creation is allowed by MPTCP limits, after= that the +each MPTCP connection is established, the MPTCP path manager will try to c= reate +an additional subflow for each known server address using this endpoint as +the source address. If the peer did not announce any additional address via +ADD_ADDR MPTCP sub-option, this has no additional effect compared to a pla= in .BR subflow -endpoint +endpoint. Otherwise, this will create an additional subflow for each recei= ved +ADD_ADDR, generating a fullmesh topology. =20 .sp .PP @@ -143,8 +159,17 @@ endpoints, additional subflows started by the peer. .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 +connection. When and ADD_ADDR suboption is accepted, if there are no local +.BR fullmesh +endpoint, the MPTCP path manager will try to create a new subflow towards = the +address specified by the ADD_ADDR option, using as source the local address +obtained by the routing resolution. Otherwise, the MPTCP path manager will= try +to create a new subflow for each +.BR fullmesh +endpoint, using the fullmesh endpoint as the source address and the address +specified by the ADD_ADDR option as the destination. In both cases the MPT= CP +path manager enforces +the .IR SUBFLOW_NR limit. =20 --=20 2.33.1