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

Karsten Desler
2004-12-08T13:27:07Z

* 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