From patchwork Tue Jul 28 22:12:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mat Martineau X-Patchwork-Id: 1338052 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4BGWBP3dQGz9sRN for ; Wed, 29 Jul 2020 08:12:29 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729835AbgG1WMW (ORCPT ); Tue, 28 Jul 2020 18:12:22 -0400 Received: from mga02.intel.com ([134.134.136.20]:2589 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729797AbgG1WMT (ORCPT ); Tue, 28 Jul 2020 18:12:19 -0400 IronPort-SDR: /jiMdQ34wsWTwyu0TRaEJFJr1L5TUmfCJ8WmSJ6a6nu34BjpaP0c8D1nHB2eFrDLTQ/ba1U7NI RIhEqHVGa51A== X-IronPort-AV: E=McAfee;i="6000,8403,9696"; a="139342693" X-IronPort-AV: E=Sophos;i="5.75,408,1589266800"; d="scan'208";a="139342693" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2020 15:12:15 -0700 IronPort-SDR: wq0mY1CpY5uPgQ0pdFmwwHq/qW/m58SvewZQv7SUqejRgYbIK9phbo0afYzFkj3Xp4zAsVaGlg QmA8K5Q/qZqw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,408,1589266800"; d="scan'208";a="328468893" Received: from mjmartin-nuc02.amr.corp.intel.com ([10.254.116.118]) by FMSMGA003.fm.intel.com with ESMTP; 28 Jul 2020 15:12:15 -0700 From: Mat Martineau To: netdev@vger.kernel.org Cc: Mat Martineau , mptcp@lists.01.org, matthieu.baerts@tessares.net, pabeni@redhat.com Subject: [PATCH net-next 10/12] mptcp: Skip unnecessary skb extension allocation for bare acks Date: Tue, 28 Jul 2020 15:12:08 -0700 Message-Id: <20200728221210.92841-11-mathew.j.martineau@linux.intel.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200728221210.92841-1-mathew.j.martineau@linux.intel.com> References: <20200728221210.92841-1-mathew.j.martineau@linux.intel.com> MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Bare TCP ack skbs are freed right after MPTCP sees them, so the work to allocate, zero, and populate the MPTCP skb extension is wasted. Detect these skbs and do not add skb extensions to them. Signed-off-by: Mat Martineau --- net/mptcp/options.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/mptcp/options.c b/net/mptcp/options.c index b4458ecd01f8..7fa822b55c34 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -868,15 +868,18 @@ void mptcp_incoming_options(struct sock *sk, struct sk_buff *skb, if (mp_opt.use_ack) update_una(msk, &mp_opt); - /* Zero-length packets, like bare ACKs carrying a DATA_FIN, are - * dropped by the caller and not propagated to the MPTCP layer. - * Copy the DATA_FIN information now. + /* Zero-data-length packets are dropped by the caller and not + * propagated to the MPTCP layer, so the skb extension does not + * need to be allocated or populated. DATA_FIN information, if + * present, needs to be updated here before the skb is freed. */ if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq) { if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq) && schedule_work(&msk->work)) sock_hold(subflow->conn); + + return; } mpext = skb_ext_add(skb, SKB_EXT_MPTCP);