From mboxrd@z Thu Jan 1 00:00:00 1970 From: P@draigBrady.com Subject: Re: [ANNOUNCE] nf-hipac v0.8 released Date: Wed, 02 Jul 2003 14:08:52 +0100 Sender: netdev-bounce@oss.sgi.com Message-ID: <3F02D964.7050301@draigBrady.com> References: <200307021426.56138.nf@hipac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Pekka Savola , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Return-path: To: nf@hipac.org In-Reply-To: <200307021426.56138.nf@hipac.org> Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org Michael Bellion and Thomas Heinz wrote: > Hi Pekka >=20 >=20 >>Thanks for your clarification. We've also conducted some tests with >>bridging firewall functionality, and we're very pleased with nf-hipac's >>performance! Results below. >=20 >=20 > Great, thanks a lot. Your tests are very interesting for us as we haven= 't done=20 > any gigabit or SMP tests yet.=20 >=20 >>In the measurements, tests were run through a bridging Linux firewall, >>with a netperf UDP stream of 1450 byte packets (launched from a differe= nt >>computer connected with gigabit ethernet), with a varying amount of >>filtering rules checks for each packet. >>I don't have the specs of the Linux PC hardware handy, but I recall >>they're *very* highend dual-P4's, like 2.4Ghz, very fast PCI bus, etc. >=20 > Since real world network traffic always consists of a lot of different = sized=20 > packets taking maximum sized packets is very euphemistic. 1450 byte pac= kets=20 > at 950 Mbit/s correspond to approx. 80,000 packets/sec. > We are really interested in how our algorithm performs at higher packet= rates.=20 > Our performance tests are based on 100 Mbit hardware so we coudn't test= with=20 > more than approx. 80,000 packets/sec even with minimum sized packets. Interrupt latency is the problem here. You'll require napi et. al to get over this hump. > At this=20 > packet rate we were hardly able to drive the algorithm to its limit, ev= en=20 > with more than 25000 rules involved (and our test system was 1.3 GHz=20 > 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=E1draig.