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, 25 Nov 2011 09:55:32 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	jhs@...atatu.com, hadi@...erus.ca, netdev <netdev@...r.kernel.org>,
	dev@...nvswitch.org, David Miller <davem@...emloft.net>,
	Chris Wright <chrisw@...hat.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Eric Dumazet <eric.dumazet@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Justin Pettit <jpettit@...ira.com>
Subject: Re: Open vSwitch Design

On Thu, Nov 24, 2011 at 9:20 PM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> On Thu, 24 Nov 2011 17:30:33 -0500
> jamal <hadi@...erus.ca> wrote:
>> On Thu, 2011-11-24 at 12:10 -0800, Jesse Gross wrote:
>> >  * Userspace interfaces:  One of the difficulties of having a
>> > specialized, exact match flow lookup engine is maintaining
>> > compatibility across differing kernel/userspace versions.  This
>> > compatibility shows up heavily in the userspace interfaces and is
>> > achieved by passing the kernel's version of the flow along with packet
>> > information.  This allows userspace to install appropriate flows even
>> > if its interpretation of a packet differs from the kernel's without
>> > version checks or maintaining multiple implementations of the flow
>> > extraction code in the kernel.
>>
>> I didnt quiet follow - are we talking about backward/forward
>> compatibility?
>
> The problem is that there are two flow classifiers, one in OpenVswitch
> in the kernel, and the other in the user space flow manager. I think the
> issue is that the two have different code.

Yes, since userspace is installing exact match entries, these flows
obviously need to be of the same form that the kernel would extract
from the packet.  Over time, I'm sure that additional packet formats
will be added so it's important to handle the case where there is a
mismatch.

> Is the kernel/userspace API for OpenVswitch nailed down and documented
> well enough that alternative control plane software could be built?

Yes, that's actually the reason why it took so long to actually submit
the code for upstream - we spent a lot of time cleaning up and
stripping down the interfaces so they could be locked down (or cleanly
extended).

There's a fair amount of documentation on how to maintain
compatibility for flows as mentioned above in the patch that I
submitted and we're certainly happy to write more if other things are
unclear.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ