On Sat, Jul 29, 2017 at 7:25 PM, Neal Cardwell <ncardw...@google.com> wrote: > On Thu, Jul 27, 2017 at 7:31 PM, Florian Westphal <f...@strlen.de> wrote: >> 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? >> >> Florian Westphal (6): >> tcp: remove prequeue support >> tcp: reindent two spots after prequeue removal >> tcp: remove low_latency sysctl >> tcp: remove header prediction >> tcp: remove CA_ACK_SLOWPATH >> tcp: remove unused mib counters >> >> Documentation/networking/ip-sysctl.txt | 7 >> include/linux/tcp.h | 15 - >> include/net/tcp.h | 40 ---- >> include/uapi/linux/snmp.h | 8 >> net/ipv4/proc.c | 8 >> net/ipv4/sysctl_net_ipv4.c | 3 >> net/ipv4/tcp.c | 109 ----------- >> net/ipv4/tcp_input.c | 303 >> +++------------------------------ >> net/ipv4/tcp_ipv4.c | 63 ------ >> net/ipv4/tcp_minisocks.c | 3 >> net/ipv4/tcp_output.c | 2 >> net/ipv4/tcp_timer.c | 12 - >> net/ipv4/tcp_westwood.c | 31 --- >> net/ipv6/tcp_ipv6.c | 3 >> 14 files changed, 43 insertions(+), 564 deletions(-) >> > > I unconditionally support the removal of prequeue support. > > For the header prediction code: IMHO before removing the header > prediction code it would be useful to do some kind of before-and-after > benchmarking on a low-powered device where battery life is the main > concern. I am thinking about ARM-based cell phones, IoT/embedded > devices, raspberry pi, etc. You mention GRO helping to make header > prediction obsolete, but in those devices packets arrive so slowly > that probably GRO does not help. With slow CPUs and battery life the > main concern, it seems conceivable to me that header prediction might > still be a win (and worth keeping, since the complexity cost is
by the time these devices use 4.12 kernels they are likely powerful enough to make header prediction irrelevant... > largely in the past; the maintenance overhead has been low). Just a > thought. > > thanks, > neal
