Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Aug 2003 17:05:42 -0700
From:      Sam Leffler <sam@errno.com>
To:        John Polstra <jdp@polstra.com>, net@freebsd.org
Subject:   Re: bpf, ipfw and before-and-after
Message-ID:  <1566283957.1060103142@melange.errno.com>
In-Reply-To: <200308052353.h75Nr2qC007206@strings.polstra.com>
References:  <20030805133922.GA7713@k7.mavetju> <01ca01c35b86$83c75590$812a40c1@PETEX31> <200308052101.h75L1WR1006787@strings.polstra.com> <1564916751.1060101774@melange.errno.com> <200308052353.h75Nr2qC007206@strings.polstra.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> In article <1564916751.1060101774@melange.errno.com>,
> Sam Leffler  <sam@errno.com> wrote:
>> > My point is that the extra calls to bpf_mtap would harm performance
>> > even when bpf wasn't being used.
>>
>> In -current I believe all the calls are prefixed with a check for
>> ifp->if_bpf or similar.  So any slow down should only happen when BPF is
>> active.
>
> That does not follow, because the check of ifp->if_bpf itself takes
> time.  There is no way to avoid the performance penalty except at
> compile time.  Yes, branch prediction helps, but it doesn't eliminate
> the problem.  Even with gigabit ethernet those individual nanoseconds
> add up quickly to the point where they matter.  With 10 Gb ethernet on
> the way, it will only get worse.

You said there were calls to bpf_mtag and they would add noticeable 
overhead even when BPF was not in use.  I said these are only made when BPF 
is in use.  What doesn't follow?

I'm not arguing about keeping up with 10Gb media...

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1566283957.1060103142>