On Tuesday 26 April 2016 08:43 PM, Ben Pfaff wrote:
On Mon, Apr 25, 2016 at 04:41:40PM +0530, Babu Shanmugam wrote:
On Friday 22 April 2016 10:51 PM, Ben Pfaff wrote:
On Fri, Apr 22, 2016 at 12:44:12PM +0530, bscha...@redhat.com wrote:
From: Babu Shanmugam <bscha...@redhat.com>
Following are done through this series
1. Changed the old approach of policing the packets. It is now shaped
with queues. Changed the Logical_Port options for NB db
2. Support of DSCP marking through options field in Logical_Port table
Babu Shanmugam (2):
ovn: Replace the QOS policing parameters with the usage of QOS table
ovn: QOS DSCP markings for ports
Have you tested this? There are at least two aspects that seem relevant
to testing. First, propagating queuing through tunnels is somewhat
indirect and one needs to make sure that the QoS configuration actually
makes it to the physical device. Second, HTB has a reputation for poor
quality for links above about 1 Gbps, which isn't very fast
anymore--that's why we also support HFSC.
Ben, I have not tested these aspects. The reason I used HTB is mainly
because it supports
burst setting. From vswithc.conf.db man page, HFSC does not seem to have an
option
for burst setting.
I could not understand how "propagating queuing through tunnels is somewhat
indirect". I can test it if you
can give some more information on the problem.
Usually for shaping it only makes sense to configure it on the physical
NIC network device. Does your series do that? If you haven't tested
it, it's hard for me to imagine it working.
Why is burst setting valuable?
I tried testing the HTB rate params on a veth device. It seems to work.
Thanks to iperf, we can see that it tries to control the traffic
egressing the veth device. With out the HTB queue, it occupies the full
bandwidth.
I faced some problems while testing. How much ever max-rate I try to set
in the Queue table, I get a kernel warning "HTB: quantum of class 1FFFE
is big. Consider r2q change". I see that OVS is using r2q = 10. I tried
a rate as high as 20000 to as low as 600, it still gives me that
message. Because of this the kernel assigns a fixed quantum of 200000
always. I am still debugging this.
Openstack QOS policies demands burst setting as part of bandwidth rules.
But, I am not sure how to get the burst working in HFSC.
Thank you,
Babu
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
