On Thu, Nov 22, 2018 at 10:01 AM Neal Cardwell <ncardw...@google.com> wrote: > > On Wed, Nov 21, 2018 at 12:52 PM Eric Dumazet <eduma...@google.com> wrote: > > > > In case GRO is not as efficient as it should be or disabled, > > we might have a user thread trapped in __release_sock() while > > softirq handler flood packets up to the point we have to drop. > > > > This patch balances work done from user thread and softirq, > > to give more chances to __release_sock() to complete its work. > > > > This also helps if we receive many ACK packets, since GRO > > does not aggregate them. > > Would this coalesce duplicate incoming ACK packets? Is there a risk > that this would eliminate incoming dupacks needed for fast recovery in > non-SACK connections? Perhaps pure ACKs should only be coalesced if > the ACK field is different?
Yes, I was considering properly filtering SACK as a refinement later [1] but you raise a valid point for alien stacks that are not yet using SACK :/ [1] This version of the patch will not aggregate sacks since the memcmp() on tcp options would fail. Neal can you double check if cake_ack_filter() does not have the issue you just mentioned ?
