Comment 7 for bug 1858610
Revision history for this message
| Rodolfo Alonso (rodolfo-alonso-hernandez) wrote | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Hi @Jie:
About your last comment.
[DB model]
I don't see the need of this new QoS policy. Instead of this, what you should create is a QoS maxBW shared rule. The ports having this shared maxBW rule will share the network BW.
A QoS policy can't have both maxBW and shared maxBW; those rules are incompatibles. This should be checked first.
[Neutron server]
What you need to capture are the port updates/creation. When a port receives a QoS policy with a shared maxBW rule, you need to check if the port is bound. If so, then you need to send an update to the driver to handle this.
Another problem could be what to do with ports having the same shared maxBW rule but attached to different VMs or hosts. In this case, how are you going to apply the maxBW shared rule? Are you going to block the port binding?
[Linux Bridge]
What you propose is to join and redirect all tap devices through a IFB block, to control in a single place the BW of all ports. This has a disadvantage: all the traffic associated to those VM ports will be funnelled through this IFB block. This can reduce the max I/O throughput but this could be acceptable for this feature.
[OVS]
I don't agree with implementing the same solution as in LB. This architecture [1] was abandoned in favor of connecting the TAP device directly to the integration bridge. This architecture is compatible with OVS-DPDK and HW offload features. You need to make a good architecture proposal here to make this change compatible with current OVS features and VNIC types, and for being accepted in the Neutron community.
Regards.
[1] https:/