netdev - Re: [patch net-next] tc: introduce OpenFlow classifier

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150327060716.GB2073@nanopsycho.orion>
Date:	Fri, 27 Mar 2015 07:07:16 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
	tgraf@...g.ch, jesse@...ira.com
Subject: Re: [patch net-next] tc: introduce OpenFlow classifier

Thu, Mar 26, 2015 at 09:39:11PM CET, hannes@...essinduktion.org wrote:
>On Thu, Mar 26, 2015, at 16:29, Jiri Pirko wrote:
>> Thu, Mar 26, 2015 at 03:23:56PM CET, hannes@...essinduktion.org wrote:
>> >> +static int of_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>> >> +		       struct tcf_result *res)
>> >> +{
>> >> +	struct cls_of_head *head = rcu_dereference_bh(tp->root);
>> >> +	struct cls_of_filter *f;
>> >> +	struct of_flow_key skb_key;
>> >> +	int ret;
>> >> +
>> >> +	of_extract_key(skb, &skb_key);
>> >> +
>> >> +	list_for_each_entry_rcu(f, &head->filters, list) {
>> >> +		if (!of_match(&skb_key, f))
>> >> +			continue;
>> >
>> >This seems very limited to me, do you have plans to extend this?
>> 
>> What do you have in mind?
>
>We have the possibility to make the order of the matches matter easily
>here (like a decision tree).
>Maybe this would give a benefit over simple full match with mask, so
>user space can align the most
>significant matches first thus creating less churn in the caches and
>make the lookup time shorter?
>I understand, if you want build a simples openvswitch replacement a hash
>table would be good to go,
>too.
>
>Just a proposal, maybe we can add more benefit to this kind of
>classifier.

Yep sure. This can be implemented in follow-up patches.

>
>Albeit it looks a bit like cls_bpf could do that more easily.

well, you can do *everything* with cls_bpf now that it supports ebpf.
But I think it is a big hammer. cls_openflow suppose to be just
replacement for existing ovs classification, with very simple and well
understood uapi.

>
>What do you think?
>
>Bye,
>Hannes
--
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