Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1113790imd; Sat, 3 Nov 2018 18:28:42 -0700 (PDT) X-Google-Smtp-Source: AJdET5cuHZp+D01gwkOsUkMCe3jCMuAJh3OQs5+BRLloC0tOR4G5+rmHFzWD+RISf2pkUGGfZBhC X-Received: by 2002:a63:d444:: with SMTP id i4-v6mr15580203pgj.194.1541294922120; Sat, 03 Nov 2018 18:28:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541294922; cv=none; d=google.com; s=arc-20160816; b=T5wJSIXrFTE8v4Lo2tO08h8L65lfCaFxH6Nvud/vdbr2WStZhlX1imO/ZbON4v6xYl awAli1HTBhMcvHirSPLCxvheILRV9mdn2H2nNL00FUtkUG1glds8+dLJ3zyF5OyX7fta hzjEE5G6Y6nt/7KMo5v8n0uKTvqBGlDpGbXtyRMpnACbnr4bhF3yjPIRZW2wuiwM8x/n Dl2dMiPg6DI4a96wGPZcZioY5jyo5jXlqX/kFBHFyoznLRvG07ErD9M18U+/3AV3rLPS K/zejmEOhnf6uXBMIomEHJuntZ5xdFGYqk0BVpNAh5I6/a2IUqmlIX5h0jjVxK19faq3 vhYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/b9er5w18faP4SozhpT6Ew/XsBbKbOrZoklPzsCSmno=; b=JTMnvzb3xd0rCQqg5K61paZAYpoSm4Yd8nmiRHcTw40n4XPWPY57NDy/MH9SI3fkJ0 KK2EdtOFpB75swqDOzP+Gz36g2ys8vMN0Es/SShvA7ozPJ+AsiUsEz4CnML1VTQmokcK bdUn5+fITLv0+MA3WuwezdbEYvdoyBN9OwOlvOE1mc1z8AFORI6jtSDa82buMZbdi73u cO0wVHYZFxn7VZPdJJhG/ulqfgYl9FsS+faoNdqEK96VygGipT0NB6B7svODBxznYWvI TyOmq0oybKHulM5RHZ1vg70fFqSuQWENXZH4A0j89nfs2nJdPkidFVYJ3rgi5Qdt7Dfs TyBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WSABywpd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h22-v6si27906444pli.240.2018.11.03.18.28.28; Sat, 03 Nov 2018 18:28:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WSABywpd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728858AbeKDKke (ORCPT + 99 others); Sun, 4 Nov 2018 05:40:34 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:34020 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727157AbeKDKke (ORCPT ); Sun, 4 Nov 2018 05:40:34 -0500 Received: by mail-it1-f193.google.com with SMTP id t189-v6so4605908itf.1; Sat, 03 Nov 2018 18:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/b9er5w18faP4SozhpT6Ew/XsBbKbOrZoklPzsCSmno=; b=WSABywpdMAPfZ5osJmLJ6U34J6ByOA+W0y1mTm7Pp9+Y9I+jVktgfcld/BoyB2zPzV RyxhxeRkcScolDA2zpITyr544zZ5kxpS7A6/rIHBrp1abmwqqG/PqaK9Gnclo+3mYjKg fzj8Q7jQL6bmnG/QxZ0Gzfew3ADN1R5Xw3z3RnYmtgWVOQk4aJ3bZIDVax39XLiCoUBZ 9nUxHQwqHNCi4b016bK7jh9n0SYIvb5ZMCx9wi9Ja4aWO9XqdacjW6vlSz5mrGyZZcZu 73wYB5BGDMuDciavPB7nKdaZN61UoJjOLLe+vURt5lHI4u0qmYk83CkT3jsmfZ8Dzw3m V04g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/b9er5w18faP4SozhpT6Ew/XsBbKbOrZoklPzsCSmno=; b=bewq4NYIokM5tqnBlm1mA/rTk/kRTZi01FQ9wcY70iPFrJLdvHVecS/J7WNK6P6obM e6pwaZeOwDmlIfe2hyFkW2FAn3mqllZaGq8QeYedaue3fhTSRSVBjDjTMvrzuaIugSSr zxSliG+61afrJCPkTLdXuoC1pkI/whrsCYLJHRxJFJctkqDo/HVg95MIGG32YSr0LCUM rk2TfpBpHdDwi7ZOqdq/4+xwkVZ3Ke4Lq4g7Kdr4OlszCM1YdGRH9qG40JsznP+od0hn oprJWae1oQtFJl+xOqhIhSjE6kIJ6Lwtey4tlGayQgL6IuhV6Fkmsyz8us4yxcdFNU1N PITg== X-Gm-Message-State: AGRZ1gIxl0pbb3lOWsIv1UEadk1KQzBhJzDFYRGVqAi1PH133dH5tq+E xacShrFeCSZxF92afLUAxuQfZoX8DUSEsbiGPJU= X-Received: by 2002:a24:140b:: with SMTP id 11-v6mr2390385itg.59.1541294849377; Sat, 03 Nov 2018 18:27:29 -0700 (PDT) MIME-Version: 1.0 References: <1541264071-9905-1-git-send-email-laoar.shao@gmail.com> <5f585304-b6f5-5f49-adcf-eaed471c0d76@gmail.com> In-Reply-To: <5f585304-b6f5-5f49-adcf-eaed471c0d76@gmail.com> From: Yafang Shao Date: Sun, 4 Nov 2018 09:26:53 +0800 Message-ID: Subject: Re: [PATCH] tcp: do not update snd_una if it is same with ack_seq To: Eric Dumazet Cc: David Miller , Eric Dumazet , netdev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 4, 2018 at 8:40 AM Eric Dumazet wrote: > > > > On 11/03/2018 09:54 AM, Yafang Shao wrote: > > In the slow path, TCP_SKB_SB(skb)->ack_seq may be same with tp->snd_una, > > and under this condition we don't need to update the snd_una. > > > > Furthermore, tcp_ack_update_window() is only called in slow path, > > so introducing this check won't affect the fast path processing. > > > > By the way, '&' is a little faster than '-', so I replaced after() with > > "flag & FLAG_SND_UNA_ADVANCED". > > > > Signed-off-by: Yafang Shao > > --- > > net/ipv4/tcp_input.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > > index 2868ef2..db5a6b7 100644 > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -3376,7 +3376,8 @@ static int tcp_ack_update_window(struct sock *sk, const struct sk_buff *skb, u32 > > } > > } > > > > - tcp_snd_una_update(tp, ack); > > + if (after(ack, tp->snd_una)) > > + tcp_snd_una_update(tp, ack); > > > > Adding this after() here is confusing, how ack could be before snd_una ? > That would be a serious bug. > ack can't be before snd_una, but it can be equal with snd_una. Seems bellow change would be more specific, if (ack != tp->snd_una) tcp_snd_una_update(tp, ack); > I do not see why another conditional has any gain here. > > You are trying to avoid very cheap operations : > > u32 delta = ack - tp->snd_una; > > tp->bytes_acked += delta; > tp->snd_una = ack; > > Maybe the real reason for this patch is not explained in the changelog ? No additional reason. I just want to avoid these uneccessary operations. Because I find that this uncessary operations always happen, especially when head prediction fails and then the packet can't go to fast path processing. Thanks Yafang