placement of postrouting

[Don Cohen]

Harald Welte writes:
 > On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote:
 > > Harald Welte writes:
 > So you want to have a big case statement _after_ enqueuing of the packet
 > happens [ i.e. in the network TX softirq], calling NF_HOOK for the 
 > respective protocol family?

Actually, after dequeuing.
I did suggest an alternative to the big case statement, which was
a new hook.  You'd loop through the registered functions.  Perhaps
these functions should be able to return something to drop the packet.

 > > ...  I think in general it would be
 > > worth while to save more of this data for use in later hooks.
 > > So I think that nat should save the original data just for use in
 > > later hooks.  
 > 
 > well, but it's added overhead and none of the existing functions within
 > the framework need it.  If there is any chance for adding such overhead,
 > then if at the same time we actually have some code which uses it.  
 > 
 > Just providing features because they are nice for some 
 > not-included-in-kernel code is not our philosophy.

Netfilter itself seems to be a counterexample to that statement.
Its whole purpose is to enhance the range of things that can be done
by not-included-in-kernel code(*).  Certainly it's worth saving a
little more data in order to increase that range further.

For any particular data this is a cost benefit question.
The cost of saving the data is to be compared with the benefit of
what can be done with that data.

(*) Now that I reread this, it occurs to me that in-kernel could mean
two different things.  The code in modules (or code that could have
been in modules) could be considered in or out.  I meant to include it
as part of what netfilter is meant to support.  The other code is
stuff like iptables rules, which I think is clearly out.  In both
cases it's useful to make something like input device available.