[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [pooka%netbsd.org@localhost: CVS commit: src/sys]
> On Wed, Jan 20, 2010 at 10:40:56PM +0100, Joerg Sonnenberger wrote:
>> ----- Forwarded message from Antti Kantee <pooka%netbsd.org@localhost> -----
>> Module Name: src
>> Committed By: pooka
>> Date: Tue Jan 19 22:08:18 UTC 2010
>> Modified Files:
>> src/sys/net: bpf.c bpf.h if_arcsubr.c if_atmsubr.c if_bridge.c
>> if_ecosubr.c if_etherip.c if_ethersubr.c if_faith.c if_fddisubr.c
>> if_gif.c if_gre.c if_hippisubr.c if_ieee1394subr.c if_loop.c
>> if_ppp.c if_pppoe.c if_sl.c if_srt.c if_stf.c if_strip.c if_tap.c
>> if_tokensubr.c if_tun.c if_vlan.c ppp_tty.c
>> Log Message:
>> Redefine bpf linkage through an always present op vector, i.e.
>> #if NBPFILTER is no longer required in the client. This change
>> doesn't yet add support for loading bpf as a module, since drivers
>> can register before bpf is attached. However, callers of bpf can
>> now be modularized.
>> ----- End forwarded message -----
>> I disagree with this change, at least the part about using a function
>> vector. This adds the overhead on an indirect call for no good reason to
>> a common code path for every single network packet, if there is a BPF
>> listener. That happens as soon as the interface is configured by DHCP.
>> The same benefit of being able to modularize BPF could be obtained by
>> pushing down the indirect calls into the actual functions. That could at
>> some future point also be optimised by binary patching. This only
>> matters of course, if someone actually wants to make BPF a module, which
>> I am not too sure about given the constrains already mentioned.
>> So please change this back to use normal function calls. It might be a
>> good time to change bpf_mtap and friends to be simple macros that
>> include the if (ifp->if_bpf) check, but that's more a cosmetic question.
> Thank you for your insightful comments. It is refreshing to see
> people truly try their best to discover problems.
> If you are concerned with dhcp machine performance, may I suggest
> you start by optimizing the thousands of instructions that bpf
> executes for every packet while trying to decide that it's not
> handling dhcp input. Also, you'd need to fix bus_space on most
> architectures to keep the damn nic drivers from doing *multiple*
> indirect calls (start with sun2, because this project will benefit
> the most from you working on that). Finally, follow up with
> binary-patching away that pesky if_input method.
if you prefer to expose bpf_ops to each drivers, i'd like to hear why.
or, do you mean that you simply don't care?
> best regards,
Main Index |
Thread Index |