netdev - Re: Integration of 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:	Fri, 2 Dec 2011 15:30:20 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	jhs@...atatu.com
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	netdev <netdev@...r.kernel.org>, dev@...nvswitch.org,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>,
	Chris Wright <chrisw@...hat.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: Integration of Open vSwitch

On Wed, Nov 30, 2011 at 5:11 AM, jamal <hadi@...erus.ca> wrote:
> On Tue, 2011-11-29 at 22:25 -0800, Jesse Gross wrote:
>> As I
>> mentioned before, I'd like to have a bit of a design discussion of
>> what it would look like if Open vSwitch were to use some of the
>> existing components (and really focus on just that).  There were a
>> number of suggestions made about using parts of the bridge, tc,
>> netfilter, etc. and some of them overlap or conflict so I don't quite
>> have a coherent solution in mind.  Would you guys mind walking through
>> what each of you envision it looking like?
>
> I'll try my TL;DR version:
> My opinion is the classifier action code needs refactoring. I have no
> doubt that it goes in as is it will eventually look like the one
> we already have. From the evolution of that code i can already see
> that is where it is going. I really dont see need to have two competing
> interfaces in that aspect. If you decide to go that way I will be
> happy to help review and make suggestions.

I completely agree with the desire to share code where there's overlap
and it makes sense (I was actually just working on some refactoring to
increase code reuse before this).

I think one of the key things to focus on is the userspace/kernel
interface since we'll have much less opportunity to significantly
change that over time.  Getting both compatibility and performance is
something that we've worked on a fair amount and have arrived at a
solution that meets the needs of OVS (and probably only OVS) pretty
well.  I think it's a nice model but keeping that while refactoring on
top of the tc layer seems challenging to do cleanly because the flow
information is needed by both the flow lookup and userspace
communication.  Stringing that through generic code seems fairly
unappealing.

So I agree with you in principle and if you are right that things tend
to converge there should be more room for code reuse over time.  Right
now though I would just focus on the high level bits.
--
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