Bug 16254

Summary: TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6
Product: Networking Reporter: Maciej Rutecki (maciej.rutecki)
Component: IPV4Assignee: Stephen Hemminger (stephen)
Status: CLOSED WILL_NOT_FIX    
Severity: normal CC: alex.shi, davem, eric.dumazet, maciej.rutecki, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.34 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 15310    

Description Maciej Rutecki 2010-06-20 06:48:02 UTC 
Subject    : TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6
Submitter  : "Alex,Shi" <alex.shi@intel.com>
Date       : 2010-06-18 7:17
Message-ID : 1276845448.2118.346.camel@debian
References : http://marc.info/?l=linux-kernel&m=127684931020672&w=2

This entry is being used for tracking a regression from 2.6.33.  Please don't
close it until the problem is fixed in the mainline.

Caused by:

commit c377411f2494a931ff7facdbb3a6839b1266bcf6
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date:   Tue, 27 Apr 2010 22:13:20 +0000 (15:13 -0700)

    net: sk_add_backlog() take rmem_alloc into account

   Current socket backlog limit is not enough to really stop DDOS attacks,
   because user thread spend many time to process a full backlog each
   round, and user might crazy spin on socket lock.

   We should add backlog size and receive_queue size (aka rmem_alloc) to
   pace writers, and let user run without being slow down too much.

   Introduce a sk_rcvqueues_full() helper, to avoid taking socket lock in
   stress situations.

   Under huge stress from a multiqueue/RPS enabled NIC, a single flow udp
   receiver can now process ~200.000 pps (instead of ~100 pps before the
   patch) on a 8 core machine.

   Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
   Signed-off-by: David S. Miller <davem@davemloft.net>

First-Bad-Commit : c377411f2494a931ff7facdbb3a6839b1266bcf6