netdev - Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.

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:	Tue, 22 Nov 2011 15:11:33 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	jhs@...atatu.com
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	dev@...nvswitch.org
Subject: Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.

On Mon, Nov 21, 2011 at 4:20 AM, jamal <hadi@...erus.ca> wrote:
> On Fri, 2011-11-18 at 15:12 -0800, Jesse Gross wrote:
>> Open vSwitch is a multilayer Ethernet switch targeted at virtualized
>> environments.  In addition to supporting a variety of features
>> expected in a traditional hardware switch, it enables fine-grained
>> programmatic extension and flow-based control of the network.
>> This control is useful in a wide variety of applications but is
>> particularly important in multi-server virtualization deployments,
>> which are often characterized by highly dynamic endpoints and the need
>> to maintain logical abstractions for multiple tenants.
>>
>> The Open vSwitch datapath provides an in-kernel fast path for packet
>> forwarding.  It is complemented by a userspace daemon, ovs-vswitchd,
>> which is able to accept configuration from a variety of sources and
>> translate it into packet processing rules.
>>
>
> So the last time we had a discussion on this on the list, we seemed
> to agree that you could use the tc classifier-action infrastructure.
> For simplicity, we agreed you will need to do a speacilized classifier.
> You may need to add a few more actions. What happened since?
>
> You are replicating a lot of code and semantic that exist (not just on
> classifier actions). You could improve the exisiting infrastructure
> instead. We are eventually going to have two competing interfaces as
> a result. You may only need 1 or 2 different classification schemes
> today and try to justify you need it for simplicity - but in a few
> months you'll need one more then another action and another and
> you'll keep adding to your infrastructure.

As you mention, one of the biggest benefits of Open vSwitch is how
simple the kernel portions are (it's less than 6000 lines).  It's
existed as an out-of-tree project for several years now so it's
actually fairly mature already and unlikely that there will be a
sudden influx of new code over the coming months.  There's already
quite a bit of functionality that has been implemented on top of it
and it's been mentioned that several other components can be written
in terms of it so I think that it's fairly generic infrastructure that
can be used in many ways.  Over time, I think it will result in a net
reduction of code in the kernel as the design is heavily focused on
delegating work to userspace.

I would view it as similar in many ways to the recently added team
device, which is based on the idea of keeping simple things simple.
--
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