netdev - Re: [GIT PULL v2] Open vSwitch

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:	Wed, 23 Nov 2011 07:22:56 -0500
From:	jamal <hadi@...erus.ca>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, jesse@...ira.com,
	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [GIT PULL v2] Open vSwitch

On Wed, 2011-11-23 at 15:54 +0800, Herbert Xu wrote:

> I mostly agree with Jamal.  As far as the concept of a policy
> lookup cache goes (which appears to be at the core of OVS), this
> almost fits exactly onto a u32 hash table.  All that would be needed
> is to add the tail end of the policies, e.g., with new packet
> actions.

For a classifier, u32 or em matches would do the job  - but they may
need a wrapper around it in user space; so from a usability pov, it
would make sense to have a new classifier that is specific to them.
All the VLAN actions could go into one tc action; the checksum action
is already present. The IP/TCP/UDP header re-writes may require 
their own actions - I think one would be sufficient for all.
So in my estimate one classifier and two actions.
Then you get rid of half the code (they use generic netlink to set/get
policies)

> However, this is purely based on my conceptual view of OVS, which
> may or may not be accurate.  I'll dig into the patches over the
> next couple of days to see if they could be easily turned into
> packet actions or whether this is difficult for reasons that we
> have not yet discovered.
> 

I cant find one - you may. After staring at the code, I am also now
questioning if the existing bridge code couldnt have been re-used with
some small tweaks.
The virtual ports attached to the bridging code may be needed.
A lot of the multi-tenancy intelligence belongs in user space controller
(my reading was that was justification for not re-using bridging code 
as is).

cheers,
jamal

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