Merge branch 'tcp-remove-prequeue-and-header-prediction'
authorDavid S. Miller <davem@davemloft.net>
Mon, 31 Jul 2017 21:37:50 +0000 (14:37 -0700)
committerDavid S. Miller <davem@davemloft.net>
Mon, 31 Jul 2017 21:37:50 +0000 (14:37 -0700)
commit834e0ecf8109ee92184b9616bdc3aca6fe934f38
treee140be00bcab8b8e0cdd48be63a5bd14e92e6eec
parent764646b08d09d29adced740c26447ecdaabc9088
parent3282e65558b3651e230ee985c174c35cb2fedaf1
Merge branch 'tcp-remove-prequeue-and-header-prediction'

Florian Westphal says:

====================
tcp: remove prequeue and header prediction

During a hallway discussion with Eric Dumazet at Netdev 1.2 in
Tokyo some maybe-not-so-useful-anymore TCP stack features came up,
among these header prediction and prequeueing.

In brief, TCP prequeue assumes a single-process-blocking-read design,
which is not that common anymore. The most frequently used high-performance
networking program that is an excellent fit for these features is netperf.

The idea behind prequeueing is to move part of tcp processing, including
retransmit queue cleaning, to process context.

With (e)poll designs, prequeue is always skipped, so for such programs
this is dead-code removal.

Header prediction is also less useful nowadays.
For packet trains, GRO will do packet aggregation so we do not get the
per-packet benefit that this had before GRO anymore.

Because of SACK, header prediction also will be ineffective once
a connection suffers even light packet losses.

code removal aside, after this change processing always occurs in BH
context, this allows to experiment e.g. with doing bulk freeing of
skb heads when incoming ACKs clean packets from the retransmit queue.

There are no changes since the RFC, except in last patch (i missed
another no-longer-used mib counter). I also edited a few commit messages.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>