Re: _High_ CPU usage while routing (mostly) small UDP packets

[Karsten Desler <kdesler@soohrt.org>]

* jamal wrote:
> On Tue, 2004-12-07 at 16:10, Karsten Desler wrote:
> > I totally forgot to mention: There are approximately 100k concurrent
> > flows.
> 
> ;-> Aha. That would make a huge difference. I know of noone
> who has actually done this level of testing. I have tried upto about 50K
> flows myself in early 2.6.x and was eventually compute bound.
> Really try compiling out totaly iptables/netfilter - it will make a
> difference.

Unfortunately I need netfilter (for now, I haven't had time to look into
replacing the rules with tc yet).

> You may also want to try something like LC trie algorithm that Robert
> and co are playing with to see if it makes a difference with this many
> flows.

On a scale of one to ten, one being "will crash on the first packet",
five being "will allow moderate load, but is probably going to crash
under high load" and ten being "rock stable" how would the patch be rated?
The announcement doesn't look too promising:
| Locking.
| Not yet done.

Also when looking at the profiles, fib_* isn't showing up at (not even
near) the top. Testworthy none the less?

ip route|wc -l:
40

profile:
     4 fib_validate_source                        0.0064
    39 fib_semantic_match                         0.1875
[...]
    76 ipt_route_hook                             1.5833
   219 __kmalloc                                  1.7109
   985 e1000_clean_tx_irq                         1.8107
   157 kmem_cache_alloc                           1.9625
   405 skb_release_data                           2.5312
   633 eth_type_trans                             2.6375
   394 handle_IRQ_event                           3.5179
  1017 __kfree_skb                                3.9727
   989 alloc_skb                                  4.1208
  1645 ip_route_input                             4.6733
  5128 ipt_do_table                               6.1635
  1678 e1000_intr                                 6.9917
   289 _read_unlock_bh                           18.0625
   616 _read_lock_bh                             19.2500
   418 _spin_lock                                26.1250
  2076 e1000_irq_enable                          43.2500
   881 _spin_unlock_irqrestore                   55.0625
 96895 default_idle                             1513.9844

Cheers,
 Karsten