On Thu, Apr 30, 2015 at 06:09:25PM +0200, Daniel Borkmann wrote: > I think both have different use cases, though, but on cls_bpf side you > have maps infrastructure that is evolving as well. Not really speaking > about the other remaining classifiers, however. I also don't want to go > any further into this vim vs emacs debate. ;) And, personally, I also > don't have any issue offering alternatives to users. > > However, I still disagree with moving ingress behind this artificial > barrier if it's just not necessary. I believe, in your RFC v1 patch, > you had a second ingress hook as a static key for nft, I tend to like > that much better consensus-wise. Both subsystems should not put > unnecessary barriers into their way, really. I'm evolving to think that it would be good to have a single entry point for ingress filtering. But where are the barriers? These unfounded performance claims are simply absurd, qdisc ingress barely performs a bit better just because it executes a bit less code and only in the single CPU scenario with no rules at all. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
