On Mon, Jun 06, 2016 at 02:31:03PM +0530, Babu Shanmugam wrote: > On Saturday 04 June 2016 01:17 AM, Ben Pfaff wrote: > >On Wed, May 25, 2016 at 03:35:44PM +0530, bscha...@redhat.com wrote: > >I'm a little worried about the way that this will re-set all of the > >queues on every iteration through the ovn-controller main loop. That > >could have some performance drawbacks. However, maybe it's not worth > >worrying about it until it's a real problem in practice. > > I think setup_qos() does not touch the queues whose parameters are > consistent with the qos_settings on the logical_port. > It will modify the queues only when there is a change in the logical_ports.
You're right. It does still go to the kernel to dump all the queues, which is the expensive part in the common case. I guess I won't worry about it until it's a problem. > >This patch makes ovn-controller configure queues directly on the egress > >interface. That is completely fine. However, it means that if the > >egress interface is on an OVS bridge (which is often reasonable, > >especially if bonding is involved), then ovs-vswitchd will fight with > >ovn-controller for control of the queues. This is a long-time issue in > >ovs-vswitchd, and there has been previous discussion: > > http://openvswitch.org/pipermail/discuss/2015-May/017687.html > >(Currently, I favor the solution proposed there of adding a new QoS > >type.) > > I too feel that new Qos type is a better solution. I could not locate the > code which handles the new type, is it already available? None of the solutions presented there has been implemented. > >I don't think it's a good assumption that all the tunnels share the same > >egress interface. > > I agree to this. So, we now have to set queues on all possible egreess > interfaces. Is my understanding correct? Yes. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
