Re: [pooka%netbsd.org@localhost: CVS commit: src/sys]

[Antti Kantee <pooka%NetBSD.org@localhost>]

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:
>       [snip]
>       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.

best regards,
  antti