> 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.
gc_min_interval = 0
max_size = 262144