From: Eric Dumazet <eric.duma...@gmail.com> Date: Wed, 27 Apr 2016 10:12:25 -0700
> From: Eric Dumazet <eduma...@google.com> > > TCP prequeue goal is to defer processing of incoming packets > to user space thread currently blocked in a recvmsg() system call. > > Intent is to spend less time processing these packets on behalf > of softirq handler, as softirq handler is unfair to normal process > scheduler decisions, as it might interrupt threads that do not > even use networking. > > Current prequeue implementation has following issues : > > 1) It only checks size of the prequeue against sk_rcvbuf > > It was fine 15 years ago when sk_rcvbuf was in the 64KB vicinity. > But we now have ~8MB values to cope with modern networking needs. > We have to add sk_rmem_alloc in the equation, since out of order > packets can definitely use up to sk_rcvbuf memory themselves. > > 2) Even with a fixed memory truesize check, prequeue can be filled > by thousands of packets. When prequeue needs to be flushed, either > from sofirq context (in tcp_prequeue() or timer code), or process > context (in tcp_prequeue_process()), this adds a latency spike > which is often not desirable. > I added a fixed limit of 32 packets, as this translated to a max > flush time of 60 us on my test hosts. > > Also note that all packets in prequeue are not accounted for tcp_mem, > since they are not charged against sk_forward_alloc at this point. > This is probably not a big deal. > > Note that this might increase LINUX_MIB_TCPPREQUEUEDROPPED counts, > which is misnamed, as packets are not dropped at all, but rather pushed > to the stack (where they can be either consumed or dropped) > > Signed-off-by: Eric Dumazet <eduma...@google.com> There was a conflict due to the stats macro renaming, but that was trivial to resolve so I did it. Applied, thanks Eric.
