[Yahoo-eng-team] [Bug 1560963] Re: [RFE] Minimum bandwidth support (egress)
** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1560963 Title: [RFE] Minimum bandwidth support (egress) Status in neutron: Fix Released Bug description: Minimum bandwidth support (opposed to bandwidth limiting), guarantees a port minimum bandwidth when it's neighbours are consuming egress traffic and can be throttled in favor of the guaranteed port. Strict minimum bandwidth support requires scheduling cooperation, to avoid physical interfaces overcommit. This RFE addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE [2] , this work is a pre-requisite for the 2nd step. Use cases = NFV/telcos are interested in this type of rules to make sure functions don't overcommit computes, and that any spawn of the same architecture will perform exactly as expected. This RFE is a prerequisite for [1]. Which in the mean time will provide a best effort guarantee on minimum bandwidth. CSP could make use of it to provide guaranteed bandwidth for streaming, etc... Notes = Technologies like SR-IOV support that, and OVS & Linux bridge can be configured to support this type of service. Where in OvS it requires to use veth ports between bridges instead of patch ports, it introduces a performance overhead of a ~20%. Supporting this kind of rule for OvS agents must be made optional, so the administrators can choose it only when they really need it. SR-IOV seems not to incur in any performance penalty. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit- videos/presentation/supporting-network-bandwidth-guarantees-with- openstack-an-implementation-perspective [2] https://bugs.launchpad.net/neutron/+bug/1578989 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1560963/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1560963] Re: [RFE] Minimum bandwidth support (egress)
** Changed in: neutron Milestone: newton-rc1 => pike-1 ** Changed in: neutron Status: Fix Released => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1560963 Title: [RFE] Minimum bandwidth support (egress) Status in neutron: In Progress Bug description: Minimum bandwidth support (opposed to bandwidth limiting), guarantees a port minimum bandwidth when it's neighbours are consuming egress traffic and can be throttled in favor of the guaranteed port. Strict minimum bandwidth support requires scheduling cooperation, to avoid physical interfaces overcommit. This RFE addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE [2] , this work is a pre-requisite for the 2nd step. Use cases = NFV/telcos are interested in this type of rules to make sure functions don't overcommit computes, and that any spawn of the same architecture will perform exactly as expected. This RFE is a prerequisite for [1]. Which in the mean time will provide a best effort guarantee on minimum bandwidth. CSP could make use of it to provide guaranteed bandwidth for streaming, etc... Notes = Technologies like SR-IOV support that, and OVS & Linux bridge can be configured to support this type of service. Where in OvS it requires to use veth ports between bridges instead of patch ports, it introduces a performance overhead of a ~20%. Supporting this kind of rule for OvS agents must be made optional, so the administrators can choose it only when they really need it. SR-IOV seems not to incur in any performance penalty. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit- videos/presentation/supporting-network-bandwidth-guarantees-with- openstack-an-implementation-perspective [2] https://bugs.launchpad.net/neutron/+bug/1578989 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1560963/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1560963] Re: [RFE] Minimum bandwidth support (egress)
** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1560963 Title: [RFE] Minimum bandwidth support (egress) Status in neutron: Fix Released Bug description: Minimum bandwidth support (opposed to bandwidth limiting), guarantees a port minimum bandwidth when it's neighbours are consuming egress traffic and can be throttled in favor of the guaranteed port. Strict minimum bandwidth support requires scheduling cooperation, to avoid physical interfaces overcommit. This RFE addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE [2] , this work is a pre-requisite for the 2nd step. Use cases = NFV/telcos are interested in this type of rules to make sure functions don't overcommit computes, and that any spawn of the same architecture will perform exactly as expected. This RFE is a prerequisite for [1]. Which in the mean time will provide a best effort guarantee on minimum bandwidth. CSP could make use of it to provide guaranteed bandwidth for streaming, etc... Notes = Technologies like SR-IOV support that, and OVS & Linux bridge can be configured to support this type of service. Where in OvS it requires to use veth ports between bridges instead of patch ports, it introduces a performance overhead of a ~20%. Supporting this kind of rule for OvS agents must be made optional, so the administrators can choose it only when they really need it. SR-IOV seems not to incur in any performance penalty. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit- videos/presentation/supporting-network-bandwidth-guarantees-with- openstack-an-implementation-perspective [2] https://bugs.launchpad.net/neutron/+bug/1578989 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1560963/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp