netdev - Re: [PATCH 0/7 RFC] Netfilter/nf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552D07C4.1020509@mojatatu.com>
Date:	Tue, 14 Apr 2015 08:27:48 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Patrick McHardy <kaber@...sh.net>,
	David Miller <davem@...emloft.net>
CC:	pablo@...filter.org, tgraf@...g.ch,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 0/7 RFC] Netfilter/nf_tables ingress support

On 04/13/15 16:19, Patrick McHardy wrote:

> I'm going to jump in here since I think a good case for this can be
> made. It's going to be a bit longer, sorry. You can skip to the
> examples after the first three paragraphs since it's just a lot of
> TC bashing :)

Patrick, maybe i am misunderstanding.
Here I am arguing against Alexei for introducing a couple of
statements for the sake of performance and you want to put netfilter
on that code path and maybe move ingress to be dependent on netfilter
further up the stack? I know you are trying to sell the virtues
of nft but since you are busy bashing here, how about this polite
statement:
Netfilter is not known for its performance. Even with the ingress qlock
tc will outperform an equivalent operation done via netfilter.
Last i poked:
As the number of rules goes up, the performance difference goes up
significantly as well. When you mention the ingress qdisc lock
the analogy would be saying like saying "tc is overweight" when
infact netfilter is obese. tc can get better and there is effort
to get rid of the  lock (i am aware of efforts in that direction).
Having said that netfilter is more usable than tc - but that usability
is costly.

I like your example use case but I am not sure why you think those use
cases cant be trivially implemented with tc actions? I see a table
per cpu which is updated with info gleaned from arriving packets
as described by policy.
Maybe i am missing the connection.

In regards to ipt or conntrack; i am sure we could use your help
(and Pablo has been very nice to us) to make it a smoother experience.
We are trying not to replicate what you have done and therefore
reusing your code. OTOH, if i understood correctly you are talking
about replacing all these actions with ones you are going to write.
If you see issues we should fix them. Again, it would be preferable
if there are ways you can help make this even more seamless. And if
you decide you want to use something in tc we should make it smooth for
you.
But using conntrack or ipt or whatever new thing in the netfilter
code is optional for tc. Enforcing it by default is wrong. I also dont
believe in monopolies for classifiers. Sure nft is nice but i should
be able to use bpf if needed. It will make sense in some cases.
This is the design tc has. I know having a single approach as does
nft does reduce ui confusions - but even in your case a refresh is
needed (as in the introduction of nft). And i am sure that is not the
last time you'll do it. That experience transformation
is much smoother with tc when introducing a new classifier.

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html