per-interface packet filters, design approach

[Andre Oppermann]

Gleb Smirnoff wrote:
> 
> On Tue, Dec 14, 2004 at 03:03:27PM +0100, Andre Oppermann wrote:
> A>  d1. The PFIL_HOOKS API has one hook per direction per protocol and
> A>      passes the interface information to the firewall package.
> A>  d2. Should the PFIL_HOOKS API be changed and be per interface instead
> A>      of per protocol?  All firewall packages need to be modified and
> A>      we are no longer compatible with the PFIL_HOOKS API.
> 
> s/API/usage/g

See my previous mail why your proposal is broken by design.

> Andre, you are the person, who is optimizing our IP stack. Can you ask
> this question, please: if the interface has no filters associated with it,
> why the hell the packets running on it would enter firewall functions?

Listen Gleb, first and formost I'm cleaning up network stack from years
of bolt-on hackery to make it maintainable and easily understandable and
extendable again.

If there is a trade-off to be made between a few CPU cycles wasted with a
clean and structured design versus some hackery pseudo-optimization I'm
going to do the former.  This is always the more viable choice.

When looking at the BSD history one thing stands out:  Wherever we had a
very clean, concise and documented API (for example protocol independent
sockets) things started to fly.  In the network area we have the protosw
structure and API which allows to add any type of network protocol very
easily into the kernel.  This has allowed BSD to support many different
network protocols.  Most recently IPv6.  The price to pay for the small
indirection protosw has is nothing compared to the adavantages of a good
and clean API design.

History tells us that sticking to certain design principals pays off very
well and is worth some amount of performance tradeoffs.  Feel free to ask
Kirk McKusick on this lession of history.

-- 
Andre