From nobody Thu Apr 25 02:07:53 2024 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a02:cbb9:0:0:0:0:0 with SMTP id v25csp2394150jap; Fri, 19 Nov 2021 09:11:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJyRufW6KG9PPfDRli0dzlPNl58aPAe/nfPoArh84AXX2Q/44PTsRS+G4cUGR8kC4IDWZbu8 X-Received: by 2002:a17:90a:74c2:: with SMTP id p2mr1446354pjl.184.1637341898760; Fri, 19 Nov 2021 09:11:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637341898; cv=none; d=google.com; s=arc-20160816; b=DvOcRwLaBPj9lPKMd7Usth4KZJM+wzwovCZwHlDAqEbkS6/G0AC1QgNNUlOxCQyf3d GAaCABUv1+0j9QFm+kLD+nKFpGWOg41wtgeB2udj6zHrGgQ2dy7dURuoWwbRrgbBEiLT muJjTzVrHXOvBXIN+IYH46rt0ah69CBQne7RSKaC5dWjh2BuUPtJydNkb1Lo070THkfk 4Tyy0vOgGc6E+ci5sVhqciFT71vZAPaYhroXVd0dmCb87a1GhpjH/0Bl22WLIeA0cfk/ QptdDHfcZJc8wcXjsu1eudfqblLuaddQ8cbpsk3I9BjccgFbGhU72nA3I0K5es6I5oJM asdg== 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=ewqttHNSUu4MXADPwSdcMLgleHd9rCii9NHDwbjtjFE=; b=vMqWGFDVI/TX2hhS15+hlU6a58k1MvAAQx156okOGa4ZkCew1ihAfNPmyXjXHbiGs/ i5QIGxU4m56LjarcWLNhwEZIJKheqmYger1SMTjgIoNnmqoihSbD4XMJ7tT3hfyNUxJF Vvidjyy01a5GahtTnjpURR2ocVW9U9F2HB0NwRz04N5jQI8c9VJ4bbIy9Ydq5qaS+i9P AiA3WqwMRWulCtp1RLMW+C25AUJa0JEsGswVkfYU0vRBdTndH8bQCucMfqtVUO6kzd+V Rp+siFqGPXvpxH1rjguY9xOijJftY1yGhxZOJPmFomNoNQZc7W7u9jxTTTcvdrOGNhH9 S+bA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BSEWDlt7; spf=pass (google.com: domain of mptcp+bounces-2482-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) smtp.mailfrom="mptcp+bounces-2482-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. [147.75.197.195]) by mx.google.com with ESMTPS id f126si710745pgc.202.2021.11.19.09.11.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Nov 2021 09:11:38 -0800 (PST) Received-SPF: pass (google.com: domain of mptcp+bounces-2482-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) client-ip=147.75.197.195; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BSEWDlt7; spf=pass (google.com: domain of mptcp+bounces-2482-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) smtp.mailfrom="mptcp+bounces-2482-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 514571C0A68 for ; Fri, 19 Nov 2021 17:11:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F0ECF2C83; Fri, 19 Nov 2021 17:11:35 +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 874752C82 for ; Fri, 19 Nov 2021 17:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637341893; 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=ewqttHNSUu4MXADPwSdcMLgleHd9rCii9NHDwbjtjFE=; b=BSEWDlt7PVKVEmpWjJvEfmiLQoLoU1lIiXgOj1hqdt+1yvNvBh1DcZk+4/vEHpZj3R3QlF aDsou4YDcdrzB2JEQOXAyNhzg310l0fLQQrfZP7DqESYvKDnaqbekBVtzppMnkwovmPzAE grkq2TsVoW+ziKKZFUxdzT/VoeOTaAg= 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-62-Go5Ldpd0MYS-lAoQPt-oRA-1; Fri, 19 Nov 2021 12:11:31 -0500 X-MC-Unique: Go5Ldpd0MYS-lAoQPt-oRA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3438910144E1 for ; Fri, 19 Nov 2021 17:11:30 +0000 (UTC) Received: from gerbillo.redhat.com (unknown [10.39.193.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 99AC95DAA5 for ; Fri, 19 Nov 2021 17:11:29 +0000 (UTC) From: Paolo Abeni To: mptcp@lists.linux.dev Subject: [PATCH iproute2-next v2] mptcp: add support for fullmesh flag Date: Fri, 19 Nov 2021 18:11:24 +0100 Message-Id: <3cf6dedcf575552e4c28f153b5b59ba4ac606953.1637341866.git.pabeni@redhat.com> 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.14 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 Acked-by: Mat Martineau --- v1 -> v2: - included Mat's suggestions - extended ADD_ADDR_ACCEPTED_NR description --- 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..5a486ad1 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 specificed number of ADD_ADDR +sub-options, any other incoming one will be ignored for the MPTCP connecti= on +lifetime. When and 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=20 +.IR fullmesh +endpoints are available, the MPTCP path manager will try to create new sub= flows=20 +using each=20 +.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