One reason to leave it where it is is that sfq can drop packets others than the one currently handled if the queue becomes full. You don't want packets beeing dropped because of another one you're going to drop in POSTROUTING anyway. Other qdiscs limit bandwidth, they couldn't make any calculations about in-use bandwidth if they don't know for sure the packet is going out.
Patrick Don Cohen wrote: > 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.
