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

quoted

On Mon, 2011-11-28 at 13:54 +0000, Fischer, Anna wrote:

quoted

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.

quoted

quoted

The path up to user-space needs to be designed in a multi-queue

fashion, so that

quoted

quoted

each vPort has its own queue up to user-space. Ideally those queues

also need to

quoted

quoted

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.