[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1427402351.2093330.245738573.1406B9EA@webmail.messagingengine.com>
Date: Thu, 26 Mar 2015 21:39:11 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Jiri Pirko <jiri@...nulli.us>
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
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.
Albeit it looks a bit like cls_bpf could do that more easily.
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
Powered by blists - more mailing lists