From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit
 queue
Date: Tue, 06 Feb 2018 07:52:18 -0800
Message-ID: <1517932338.3715.149.camel@gmail.com>
References: <20171006052127.19913-1-edumazet@google.com>
         <20171007.003134.133270352885522371.davem@davemloft.net>
         <0d6ba40c-8c17-5d43-f4a1-359ce65d961f@mellanox.com>
         <CANn89i+k0jYm=thJZ66ZJh2ryc222jfmRi_AxVZt8uNE2QMJMA@mail.gmail.com>
         <e2d2db0f-94d7-dc1e-f99c-b419d50fbdcc@mellanox.com>
         <1516806544.3715.18.camel@gmail.com>
         <cca4fbc1-b8f5-6c98-112a-288a93f5f0e1@mellanox.com>
         <CANn89iK6CMAefxZDZ4eD1DJbtr-NUHfRhCsbtz02TsMgipnd=A@mail.gmail.com>
         <db881824dd3c4fc1b7b7b9e7f7489a80@AcuMS.aculab.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: David Miller <davem@davemloft.net>,
        "ncardwell@google.com" <ncardwell@google.com>,
        "ycheng@google.com" <ycheng@google.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Saeed Mahameed <saeedm@mellanox.com>,
        Tariq Toukan <tariqt@mellanox.com>,
        Amir Ancel <amira@mellanox.com>
To: David Laight <David.Laight@ACULAB.COM>,
        'Eric Dumazet' <edumazet@google.com>,
        Tal Gilboa <talgi@mellanox.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf0-f170.google.com ([209.85.192.170]:36860 "EHLO
        mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752259AbeBFPwW (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 6 Feb 2018 10:52:22 -0500
Received: by mail-pf0-f170.google.com with SMTP id k5so775500pff.3
        for <netdev@vger.kernel.org>; Tue, 06 Feb 2018 07:52:22 -0800 (PST)
In-Reply-To: <db881824dd3c4fc1b7b7b9e7f7489a80@AcuMS.aculab.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, 2018-02-06 at 15:22 +0000, David Laight wrote:
> From: Eric Dumazet
> > Sent: 06 February 2018 14:20
> 
> ...
> > Please give exact details.
> > Sending 64, 128, 256 or 512 bytes at a time on TCP_STREAM makes little sense.
> > We are not optimizing stack for pathological cases, sorry.
> 
> There are plenty of workloads which are not bulk data and where multiple
> small buffers get sent at unknown intervals (which may be back to back).
> Such connections have to have Nagle disabled because the Nagle delays
> are 'horrid'.
> Clearly lost packets can cause delays, but they are rare on local networks.

Auto corking makes sure aggregation happens, even for when Nagle is in
the picture.

netperf -- -m 256    will still cook 64KB TSO packets

netperf is not adding delays between each send(), unless it has been
modified.