Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Dec 2012 14:17:16 +0000
From:      David Chisnall <theraven@theravensnest.org>
To:        Aleksandr Rybalko <ray@FreeBSD.org>
Cc:        svn-src-projects@FreeBSD.org, Roman Divacky <rdivacky@FreeBSD.org>, src-committers@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org>
Subject:   Re: svn commit: r243914 - projects/bpfjit
Message-ID:  <06193EEB-C26B-4110-980B-F04A815C9871@theravensnest.org>
In-Reply-To: <20121208152447.5b2958d2.ray@freebsd.org>
References:  <201212052312.qB5NC2Hn056351@svn.freebsd.org> <20121206084936.GA58940@freebsd.org> <50C0DFB0.6030007@FreeBSD.org> <20121208152447.5b2958d2.ray@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Dec 2012, at 13:24, Aleksandr Rybalko wrote:

>> LLVM compilation took too much time to be useful:
>>=20
>> engine		filter cycles	compile cycles
>> - ---------------+---------------+----------------
>> jit-linux 	106468		33126+72796
>> jit-freebsd 	113958		48292+72796
>> llvm 		157394		380843640+72796
>> pcap 		276910		72796
>> linux	 	351391		9245+72796

As a further note: in the small print for this benchmark, it was done on =
1,000 packets.  On a typical network where you might want to use BPF, =
that's, what, 20-100ms of network traffic?  If you're changing BPF rules =
over ten times per second, then you are probably in quite an unusual =
usecase.  Alternatively, if you're on a network where 1,000 packets take =
so long to arrive that it's significant, then your packet filtering =
startup time is almost certainly not an issue - no one will notice if it =
takes even an extra few seconds before the first pigeon takes off...

David=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06193EEB-C26B-4110-980B-F04A815C9871>