| Message ID | 20191108220953.30904-1-fw@strlen.de |
|---|---|
| Headers | show
Return-Path: <mptcp-bounces@lists.01.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.01.org (client-ip=198.145.21.10; helo=ml01.01.org; envelope-from=mptcp-bounces@lists.01.org; receiver=<UNKNOWN>) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=strlen.de Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 478vK90fMxz9sPL for <incoming@patchwork.ozlabs.org>; Sat, 9 Nov 2019 08:58:01 +1100 (AEDT) Received: from new-ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id A87C2100EA631; Fri, 8 Nov 2019 14:00:13 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a0a:51c0:0:12e:520::1; helo=chamillionaire.breakpoint.cc; envelope-from=fw@breakpoint.cc; receiver=<UNKNOWN> Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 73EC4100EA62D for <mptcp@lists.01.org>; Fri, 8 Nov 2019 14:00:11 -0800 (PST) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from <fw@breakpoint.cc>) id 1iTCGP-0003Xt-61; Fri, 08 Nov 2019 22:57:53 +0100 From: Florian Westphal <fw@strlen.de> To: <mptcp@lists.01.org> Date: Fri, 8 Nov 2019 23:09:47 +0100 Message-Id: <20191108220953.30904-1-fw@strlen.de> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Message-ID-Hash: ABWVWFKX353KTVW36J2XZSRKYVJ2KNKA X-Message-ID-Hash: ABWVWFKX353KTVW36J2XZSRKYVJ2KNKA X-MailFrom: fw@breakpoint.cc X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.1.1 Precedence: list Subject: [MPTCP] [RFC PATCH 0/6] mptcp: add and use wmem accounting for rtx queue List-Id: Discussions regarding MPTCP upstreaming <mptcp.lists.01.org> Archived-At: <https://lists.01.org/hyperkitty/list/mptcp@lists.01.org/message/ABWVWFKX353KTVW36J2XZSRKYVJ2KNKA/> List-Archive: <https://lists.01.org/hyperkitty/list/mptcp@lists.01.org/> List-Help: <mailto:mptcp-request@lists.01.org?subject=help> List-Post: <mailto:mptcp@lists.01.org> List-Subscribe: <mailto:mptcp-join@lists.01.org> List-Unsubscribe: <mailto:mptcp-leave@lists.01.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit |
| Series |
mptcp: add and use wmem accounting for rtx queue
|
expand
|
This series adds wmem accounting and makes mptcp sockets block once the sndbuf size is reached. rtx cleanup is changed to wakeup any blocked mptcp socket once enough wmem is available again. sndbuf is set to the maximum allowed size of the tcp wmem. There is no auto-tuning, I think we can add that later on as an enhancement. This is an RFC series in order to prevent the patches from getting applied, I will send a v2 as soon as the open questions are sorted out. Everthing continues to work for me. I've tested these patches with an 4k-sized sndbuf, which results in frequent wmem blocks and mptcp connection recovers once the acks come in. 1. (see patch 5): add a new work queue or re-use existing one? 2. Should all patches get squashed or should there be a "add wmem accouting" patch? A mix of both? 2, 3 and 4 would be squash candidates for example even if we add a extra "wmem patch". I will send the next iteration of the scheduler patches after the above is sorted out. The scheduler patches have no major changes aside from addressing a comment from Paolo. Meanwhile I am working on removal of __tcp_poll and on make the mptcp socket conn list store tcp_sk structs rather than require a 'struct socket'. Florian Westphal (6): mptcp: add wmem_queued accounting mptcp: allow partial cleaning of rtx head dfrag subflow: store known available bytes in subflow options: ack pending sequence mptcp: add ack work queue sendmsg: block until mptcp sk is writeable net/mptcp/options.c | 13 ++++++-- net/mptcp/protocol.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++----- net/mptcp/protocol.h | 5 +-- net/mptcp/subflow.c | 18 ++++++++--- 4 files changed, 105 insertions(+), 17 deletions(-)