From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from mail-pl0-f43.google.com ([209.85.160.43]:43054 "EHLO
        mail-pl0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752313AbeBTPjf (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 20 Feb 2018 10:39:35 -0500
Received: by mail-pl0-f43.google.com with SMTP id f20so690388plr.10
        for <netdev@vger.kernel.org>; Tue, 20 Feb 2018 07:39:35 -0800 (PST)
Message-ID: <1519141172.55655.21.camel@gmail.com>
Subject: Re: [PATCH net-next 0/6] tcp: remove non GSO code
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Oleksandr Natalenko <oleksandr@natalenko.name>,
        Eric Dumazet <edumazet@google.com>
Cc: "David S . Miller" <davem@davemloft.net>,
        netdev <netdev@vger.kernel.org>,
        Neal Cardwell <ncardwell@google.com>,
        Yuchung Cheng <ycheng@google.com>,
        Soheil Hassas Yeganeh <soheil@google.com>
Date: Tue, 20 Feb 2018 07:39:32 -0800
In-Reply-To: <34197c670230376051d3830704f18e85@natalenko.name>
References: <20180219195652.242663-1-edumazet@google.com>
         <34197c670230376051d3830704f18e85@natalenko.name>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, 2018-02-20 at 10:32 +0100, Oleksandr Natalenko wrote:
> Hi.
> 
> 19.02.2018 20:56, Eric Dumazet wrote:
> > Switching TCP to GSO mode, relying on core networking layers
> > to perform eventual adaptation for dumb devices was overdue.
> > 
> > 1) Most TCP developments are done with TSO in mind.
> > 2) Less high-resolution timers needs to be armed for TCP-pacing
> > 3) GSO can benefit of xmit_more hint
> > 4) Receiver GRO is more effective (as if TSO was used for real on 
> > sender)
> >    -> less ACK packets and overhead.
> > 5) Write queues have less overhead (one skb holds about 64KB of 
> > payload)
> > 6) SACK coalescing just works. (no payload in skb->head)
> > 7) rtx rb-tree contains less packets, SACK is cheaper.
> > 8) Removal of legacy code. Less maintenance hassles.
> > 
> > Note that I have left the sendpage/zerocopy paths, but they probably 
> > can
> > benefit from the same strategy.
> > 
> > Thanks to Oleksandr Natalenko for reporting a performance issue for
> > BBR/fq_codel,
> > which was the main reason I worked on this patch series.
> 
> Thanks for dealing with this that fast.
> 
> Does this mean that the option to optimise internal TCP pacing is still 
> an open question?

It is not an optimization that is needed, but taking into account that
highres timers can have latencies of ~2 usec or more.

When sending 64KB TSO packets, having extra 2 usec after every ~54 usec
(at 10Gbit) has no big impact, since TCP computes a slightly inflated
pacing rate anyway.

But when sending one MSS/packet every usec, this definitely can
demonstrate a big slowdown.

But the anser is yes, I will take a look at this timer drift.