[ovs-discuss] Controller for port QoS

[Ben Pfaff]

On Wed, Sep 22, 2010 at 06:26:04PM +0900, Simon Horman wrote:
> I have been testing the port QoS feature which was recently (this June?)
> added to Open vSwitch.
> 
> As I understand it, QoS parameters are assigned to a port.
> And it is then up to the controller to assign ports to queues.

Yes.

I have considered adding a "queue" column to the Port table, which would
assign a default queue to packets that arrive at a particular port, but
I have not specified or implemented such a feature.  (That would be a
helpful contribution, if anyone wanted to contribute it.)

> I am using vs-ofctl to manually set up some flows for testing purposes,
> but this doesn't seem at all practical for non-testing.

Yes.

> Ideally I'd like for the controller to be able to
> use the out_port as part of the flow key. Actually,
> what I'm really interested in is being able to say,
> anything from port1 is assigned to a 100Mbit/s class.
> But it would also be fine for the class to be per-outgoing-port.
>
> So my question is, does using ovs-vsctl make sense for this?
> If so, does it need extending? If not, can someone offer
> a recommendation for an alternate controller?

You can't use ovs-vsctl for this right now.  ovs-vsctl just edits the
Open vSwitch database, and Open vSwitch doesn't support this feature.

You could modify ovs-controller to do this, or NOX.

> My question
> 
> For reference My current setting looks like this:
> 
> sudo ovs-vsctl set port eth1 qos=@newqos \
> 	-- --id=@newqos create qos type=linux-htb \
> 		other-config:max-rate=200000000 queues=0=@q0,1=@q1 \
> 	-- --id=@q0 create queue \
> 		other-config:min-rate=100000000 \
> 		other-config:max-rate=100000000 \
> 	-- --id=@q1 create queue \
> 		other-config:min-rate=50000000 \
> 		other-config:max-rate=50000000 
> 
> 
> vs-ofctl add-flow br0 \
> 	"in_port=3 ip nw_dst=172.17.50.253 idle_timeout=0 actions=enqueue:1:0"
> ovs-ofctl add-flow br0 \
> 	"in_port=3 ip nw_dst=172.17.50.253 idle_timeout=0 actions=enqueue:1:1"
> 
> Happily it works as expected :-)

Yes, unfortunately it doesn't scale well to more than two ports.

Another approach would be to add support for "enqueue" to the FLOOD or
NORMAL ports.  (This would be an Open vSwitch extension to OpenFlow.
I'm sure that we'd accept a contribution for such an extension, too.)
Then the rules could enqueue to a particular port on the NORMAL port.