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

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> 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.

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?

YAMAMOTO Takashi

> 
> best regards,
>   antti