From: Florian Westphal <f...@strlen.de> Date: Fri, 28 Jul 2017 01:31:11 +0200
> This RFC removes tcp prequeueing and header prediction support. > > After a hallway discussion with Eric Dumazet some > maybe-not-so-useful-anymore TCP stack features came up, HP and > Prequeue among these. > > So this RFC proposes to axe both. > > In brief, TCP prequeue assumes a single-process-blocking-read > design, which is not that common anymore, and the most frequently > used high-performance networking program that does this is netperf :) > > With more commong (e)poll designs, prequeue doesn't work. > > The idea behind prequeueing isn't so bad in itself; it moves > part of tcp processing -- including ack processing (including > retransmit queue processing) into process context. > However, removing it would not just avoid some code, for most > programs it elimiates dead code. > > As processing then always occurs in BH context, it would allow us > to experiment e.g. with bulk-freeing of skb heads when a packet acks > data on the retransmit queue. > > Header prediction is also less useful nowadays. > For packet trains, GRO will aggregate packets so we do not get > a per-packet benefit. > Header prediction will also break down with light packet loss due to SACK. > > So, In short: What do others think? I have no objections to any of this. :)
