kuznet@ms2.inr.ac.ru writes:

 > BTW what's about performance in this extremal situation?

 First I used the patch to defer all softirq's to ksoftirq with call_rcu_bh()
 patch. Sofar this has been the best combination giving both pure sofirq 
 performance and also good response from the userland apps.

 I also tried other TCP apps netperf and could note any performance 
 degradation which I was expecting.
 
 > Also, Robert, let's count the numbers again. With this change you should
 > have latency much less 100msec when priority of ksoftirqd is high.
 > So, rcu problem must be solved at current flow rates.
 > This enforces me to suspect we have another source of overflows.

 Certainly. I said to Dipankar we should not expect all overflows to disappear
 the setup I use now. But the call_rcu_bh() patch improved things so it cured 
 some latency caused by RCU. But I don't think we can do much better now in 
 terms dst overflow. 

 > F.e. one silly place could be that you set gc_min_interval via sysctl,

 I should not...

 > which uses second resolution (yup :-(). With one second you get maximal
 > ip_rt_max_size/1 second flow rate, it is _not_ a lot.

 From /proc
 gc_min_interval = 0
 max_size = 262144

 Cheers.
						--ro