Re: [PATCH 0/4] Netfilter ingress support (v3)

[Jamal Hadi Salim <jhs@mojatatu.com>]

On 05/04/15 13:43, Florian Westphal wrote:
> Jamal Hadi Salim <jhs@mojatatu.com> wrote:

>> It is an either-or choice. You cant have both.
>
> Again, why is there a need to have both (at same time)?
>

Pick your favorite distro. Do you seriously believe my tc scripts
will work by default as they used to when the distro ships
with iptables turned on? Get a freshly minted distro
and try to check what the defaults are.
I have no idea what some of these things are for but they
are there.

>> The _evil genius_ part i
>
> Please don't accuse anyone of being 'evil'.
>

It is a figure of speech and was intended to be humorous.
I consider Pablo a friend, sorry if that came out wrong.

> I think that tc and netfilter are both broken by design in the sense
> that we have two different systems with partially overlapping
> functionality while interaction between them consists of hacks.
>
> It works both ways, iptables CLASSIFY target is also not very
> elegant from a design point of view, it bolts the packet/connection matching
> functionality provided by iptables to qdisc hierarchy.
>

Well, from the tc perspective the angle has been one of laziness
and avoiding to rewrite any features that netfilter has. Essentially
a gateway-to-iptables. It has not been easy.
It does look silly if we copy things netfilter does in our view.

>> think is that distros which ship with iptables rules and conntracking
>> on are going to not even turn on tc and my scripts now have to go
>> unload one.
>
> You mean add 'rmmod nft_ingress' or something similar?
>
> That might be a problem.  One possible way out would be to
> make 'tc qdisc add dev eth0 ingress' silently unregister nft ingress
> on kernel side (but not vice versa).
>
> Not nice, but it would keep compatibility with tc ingress scripts.
>

Assuming there is something else using the nft side, now they break
because tc has taken over.

>> But even if the scripts worked (perhaps there are plans to make sure
>> all scripts continue to work transparently), i care about performance
>> and  youve suddenly taken that away from me.
>
> I don't think thats an unsolveable problem, currently we have the
> qdisc->enqueue() indirection, now we have hook + qdisc->enqueue() BUT
> AFAIU the latter could now be avoided by having ingress hook
> interact with sch_ingress directly.
>
> That being said, I am not opposed to two hooks, I just don't see any
> technical reason whatsoever why one would need two different ingress
> classification engines in use at same time.
>

What i described above.

cheers,
jamal