Hello Ihar: Please, take a look to https://review.openstack.org/#/c/318531/.
>> does it mean you want to set some queues on ports that have no qos policy >> attached? That’s exactly what I'm doing, because the unique way to shape traffic in OvS is at the end of the datapath. In other words, shaping is only possible for egress (OvS point of view) traffic. Because what I need is to limit VM-egress (OvS-ingress) traffic, what I'm doing is defined in https://review.openstack.org/#/c/318531/9/doc/source/devref/quality_of_service.rst@342. Regards. -----Original Message----- From: Ihar Hrachyshka [mailto:[email protected]] Sent: Monday, July 18, 2016 11:53 AM To: OpenStack Development Mailing List (not for usage questions) <[email protected]> Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance Rodolfo <[email protected]> wrote: > Hello: > > I’m working in the egress minimum bandwidth assurance qos policy rule. > > I made a POC using the following architecture: > - Every time a new rule is created and assigned to a port: > o A new queue is created in OVS. > o Create/update the qos policy (OVS database) in all other ports in > br-int (assigned to the same vlan), br-tun and br-phy, updating the > queue value. > o Set the queue id to the incoming traffic to the OVS. > - Every time rule is updated: > o The values are updated in the ovs database. > - Every time a rule is unassigned to a port: > o The queue is removed from the qos policies. (OVS database) > o The OVS rule to set the queue id is removed. > > The problem is, based on the neutron extensions API, I can’t make any > updates in other ports affected by this rule. That means, for example: > if I create a new port, this port must have also a qos assigned (OVS > database) using the existing queue. But because the Neutron qos rule > doesn’t apply to this port, no qos agent function is called and this > port is not correctly configured. I am sorry if the question is trivial, but just for my understanding, does it mean you want to set some queues on ports that have no qos policy attached? Why is it the case? Because if the policy IS attached to a port, then qos l2 agent driver will be triggered for all supported rules, including your new rule, on every relevant policy/rule change. I am sure I miss something, so please enlighten me. Ihar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
