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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 27 Mar 2015 11:44:02 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	netdev@...r.kernel.org, davem@...emloft.net, jhs@...atatu.com,
	jesse@...ira.com
Subject: Re: [patch net-next] tc: introduce OpenFlow classifier

On 03/27/15 at 07:07am, Jiri Pirko wrote:
> 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.

The current linear filtering approach makes it not suitable
right now. No doubt that unifying flow classification would
be great to have.

Once you start building some form of wildcarded hash tables
into this, I see a lot of overlap with cls_flow appearing.
What about extending cls_flow instead? Are you still planning
to have one cls_classifier instance per wildcard flow?

I'm usually all for small steps and take it from there but you
are setting a uapi in stone here and once you add linear
filtering behaviour you can't just undo it without a ton of
flags.
--
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