netdev - RE: [ovs-dev] Issues with openflow protocol WAS(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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 28 Nov 2011 18:54:22 +0000
From:	"Fischer, Anna" <anna.fischer@...com>
To:	Justin Pettit <jpettit@...ira.com>,
	Jamal Hadi Salim <jhs@...atatu.com>
CC:	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>
Subject: RE: [ovs-dev] Issues with openflow protocol WAS(RE: [GIT PULL v2]
 Open vSwitch

> Subject: Re: [ovs-dev] Issues with openflow protocol WAS(RE: [GIT PULL
> v2] Open vSwitch
> 
> On Nov 28, 2011, at 6:07 AM, Jamal Hadi Salim wrote:
> 
> > On Mon, 2011-11-28 at 13:54 +0000, Fischer, Anna wrote:
> >
> >> Yes, I mentioned this months ago, and I am surprised this critical
> >> issue has never been picked up on and addressed. With a flaw like
> >> this there is no chance this component can be used in any serious
> >> virtualization deployment where different customers share the same
> physical server.
> >>
> >> The path up to user-space needs to be designed in a multi-queue
> fashion, so that
> >> each vPort has its own queue up to user-space. Ideally those queues
> also need to
> >> be rate controlled in some form, so that no DoS is possible.
> >
> > Good - more folks scrutinizing openflow ;->
> 
> I realize you chair an IETF standard with overlapping goals with
> OpenFlow (ForCES), so you may have strong opinions about its design.
> However, that's not relevant to this discussion, since OpenFlow's
> design
> has nothing to do with the discussion being held here in regards to
> Open
> vSwitch.  OpenFlow is just a bullet point--although an important one--
> in
> a large set of features that Open vSwitch provides.  Its design is such
> that it should be fairly easy to include new control protocols;
> OpenFlow
> is just a library in Open vSwitch.  If you have issues with OpenFlow,
> those would be better directed to the ONF or one of the OpenFlow
> mailing
> lists.

True, and I was not interested in OpenFlow rate controlling but purely in rate controlling within the kernel for what goes up to user-space. And you addressed that with individual queues per vPort, so that solves my issues.

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