netdev - RE: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db881824dd3c4fc1b7b7b9e7f7489a80@AcuMS.aculab.com>
Date:   Tue, 6 Feb 2018 15:22:39 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Eric Dumazet' <edumazet@...gle.com>,
        Tal Gilboa <talgi@...lanox.com>
CC:     Eric Dumazet <eric.dumazet@...il.com>,
        David Miller <davem@...emloft.net>,
        "ncardwell@...gle.com" <ncardwell@...gle.com>,
        "ycheng@...gle.com" <ycheng@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Saeed Mahameed" <saeedm@...lanox.com>,
        Tariq Toukan <tariqt@...lanox.com>,
        "Amir Ancel" <amira@...lanox.com>
Subject: RE: [PATCH net-next 0/7] tcp: implement rb-tree based retransmit
 queue

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.

	David