From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
Received: from vulcan.natalenko.name ([104.207.131.136]:18084 "EHLO
        vulcan.natalenko.name" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750732AbeBTJdA (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 20 Feb 2018 04:33:00 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 20 Feb 2018 10:32:58 +0100
From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: 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>,
        Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH net-next 0/6] tcp: remove non GSO code
In-Reply-To: <20180219195652.242663-1-edumazet@google.com>
References: <20180219195652.242663-1-edumazet@google.com>
Message-ID: <34197c670230376051d3830704f18e85@natalenko.name>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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?

Oleksandr