Interrupt latency is the problem here. You'll require napi et. al
to get over this hump.
> At this
> packet rate we were hardly able to drive the algorithm to its limit, even
> with more than 25000 rules involved (and our test system was 1.3 GHz
> uniprocessor).
Cool. The same sort of test with ordinary netfilter that
I did showed it could only handle around 125 rules at this
packet rate on a 1.4GHz PIII, e1000 @ 100Mb/s.
# ./readprofile -m /boot/System.map | sort -nr | head -30
6779 total 0.0047
4441 default_idle 69.3906
787 handle_IRQ_event 7.0268
589 ip_packet_match 1.6733
433 ipt_do_table 0.6294
106 eth_type_trans 0.5521
56 kfree 0.8750
46 skb_release_data 0.3194
37 add_timer_randomness 0.1542
35 alloc_skb 0.0781
30 __kmem_cache_alloc 0.1172
27 kmalloc 0.3375
23 ip_rcv 0.0342
22 do_gettimeofday 0.1964
20 netif_rx 0.0521
19 __kfree_skb 0.0540
18 add_entropy_words 0.1023
15 __constant_c_and_count_memset 0.0938
13 batch_entropy_store 0.0813
12 kfree_skbmem 0.1071
11 netif_receive_skb 0.0208
7 nf_iterate 0.0437
7 nf_hook_slow 0.0175
6 process_backlog 0.0221
5 batch_entropy_process 0.0223
5 add_interrupt_randomness 0.0781
3 kmem_cache_free 0.0625
2 ipt_hook 0.0312
1 write_profile 0.0156
1 ip_promisc_rcv_finish 0.0208
Pádraig.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/