On Mon, Aug 15, 2016 at 3:08 PM, Paul Goyette <[email protected]> wrote: > On Mon, 15 Aug 2016, Ryota Ozaki wrote: > >> First of all, bpf (bpfjit) is different from the others. bpf sniffs >> raw packets on rx/tx in network device drivers (grep bpf_mtap) and >> also allows to send raw packets directly via ifp->if_output >> (e.g., ether_output). It doesn't provide pass/block filters that >> the others provide. >> >> bpfjit is just an optimization option of bpf. So we don't need to >> treat it individually. > > > OK, that makes sense. > >> pf, ipf and npf provide pass/block functionalities (and more) at >> hook points (grep pfil_run_hooks) in the network stack via pfil(9), >> which realizes say firewall and NAT/NAPT. They provide similar >> functions but unfortunately their functions aren't compatible and >> cannot replace one to another easily, IIUC. (Someone would explain >> details of the differences.) > > > I would very much like to know the differences. Also, can you use more than > one of them at a time?
I don't know why though, npf and pf cannot be enabled in a kernel at the same time. ipf can coexist with either. > Do they share to same "hook points" but > try to install different action routines? Yes. Each hook points has multiple actions as a list. Each action is evaluated in order; if an earlier action handles a packet, later actions won't be evaluated. > >> npf is a newer filter than the others and designed for multi-core >> systems. So basically we recommend npf when one want to use one of >> them newly. > > > Other than "it's newer", are there any significant differences between npf > vs pf or ipf? npf can run in parallel between CPU cores; that's the significant difference. Of course the benefit requires MP-ification of the network stack first. > >> BTW should we mark pf and ipf deprecated in netbsd-8 as they aren't >> well maintained nowadays? > > > Well, ipf is sort-of OK, since we at least have a reasonably complete set of > ATF tests, so if something breaks we should find out. Sure, but ATF tests cannot catch some sort of issues, for example PR 50629 and 50168. I mean we still need some efforts to keep ipf stable really. I'm worry if we have man power to keep three different similar functions stable. Shouldn't we concentrate on npf? > But pf doesn't seem > to have any tests, so we'll never know if it breaks. It sure would be nice > to not have to maintain untested code. :) :) ozaki-r
