netdev - Re: [patch net-next v3] 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 10 Apr 2015 11:12:03 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, jhs@...atatu.com, tgraf@...g.ch,
	jesse@...ira.com
Subject: Re: [patch net-next v3] tc: introduce OpenFlow classifier

Thu, Apr 09, 2015 at 11:34:23PM CEST, davem@...emloft.net wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Thu,  9 Apr 2015 14:58:07 +0200
>
>> This patch introduces OpenFlow-based filter. So far, the very essential
>> packet fields are supported (according to OpenFlow v1.4 spec).
>> 
>> This patch is only the first step. There is a lot of potential performance
>> improvements possible to implement. Also a lot of features are missing
>> now. They will be addressed in follow-up patches.
>> 
>> To the name of this classifier, I believe that "cls_openflow" is pretty
>> accurate. It is actually a OpenFlow classifier.
>> 
>> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
>
>I'm not so sure what my opinion is about whether we should
>even have an openflow classifier or not (I find major aspects
>of OpenFLOW extremely distasteful, it's basically pushing the
>SDK agenda of several major chip vendors).

Yep, I don't like OpenFlow as well. But anyway, we already have
OpenFlow-based classifier in kernel - in OVS code.

The thing is, why don't have it in tc? It does not cost anything. And
having it, people used to use ovs kernel DP will be able to migrate
easily to tc.

We can loose the name and name this cls_ngflow or something like that if
that helps.

>
>However I am sure that I majorly object to having yet another flow
>parsing engine.  Therefore, at least adjust this code to use our flow
>dissector and datastructures.  Adjust the flow dissector to fit your
>needs, if necessary.

Yep, Thomas already suggested the merge. The thing is, cls_flow uses
linked list for doing lookups. That is not scalable. in cls_openflow I
use rhashtable. Using rhashtable in cls_flow would break the existing
assumption that first inrested filter would be first hit.

So that would lead into major dual code in cls_flow. So I believe that
it is better to do it in separate cls_openflow (do one thing and do it
right).

--
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