Description of problem: allow users of Neutron network service the ability to request a particular maximum and minimum transmit bandwidth on neutron port used as pass-through vNICs Version-Release number of selected component (if applicable): How reproducible: Currently, when SR-IOV adapters are used for virtual networking, all Virtual Functions provide the same level of traffic service. It can be important for NFV use cases to provide certain level of service to specific VM network interface Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: this feature would also allow to assign all bandwitdh to a given VF, thus emulating pcipassthrough while unificating on SRIOV https://blueprints.launchpad.net/neutron/+spec/ml2-sriov-rate-limit-extension
I think more information about the QoS features found in SRIOV cards can be found in this document http://www.intel.com/content/www/us/en/network-adapters/10-gigabit-network-adapters/config-qos-with-flexible-port-partitioning.html
Max bandwidth: Work covered by: https://blueprints.launchpad.net/neutron/+spec/ml2-sriov-qos-with-bwlimiting Implemented in Liberty (OSP8) Also check: http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html Min. bandwidth: This requires neutron & nova changes. Both teams at Red Hat looking into a solution. The nova scheduler is undergoing a big change that we plan to leverage for this for providing bandwidth guarantees. But we need all those pieces being coded, plus, the integration from the neutron side. In [1] you can see a proposal for it. But we depend on [2] to make the strict min bandwidth guarantees. References: [1] https://bugs.launchpad.net/neutron/+bug/1560963 [2] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
Maximum bandwidth is covered by https://bugzilla.redhat.com/show_bug.cgi?id=1093829, hijacking this bug for minimum bandwidth.
This RFE has not been prioritized for OSP 12.
*** Bug 1396832 has been marked as a duplicate of this bug. ***
The Intel Niantic and Fortville drivers do not implement min BW, here is a screenshot for a Fortville: # ethtool -i enp24s0f1 driver: i40e version: 2.3.2-k firmware-version: 6.01 0x80003483 1.1747.0 expansion-rom-version: bus-info: 0000:18:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes # ip link set enp24s0f1 vf 0 min_tx_rate 1 RTNETLINK answers: Invalid argument So this Neutron feature will be supported only by NICs that implements it in their driver. Mellanox ConnectX-5 for instance is implementing this functionality.
Per Pavan C's request follow up from our Networking Team - Both ixgbe (for Niantic) and i40e (for Fortville) drivers implemented the set_vf_bw function, but the min_tx_rate can only be the value of 0 for both drivers. The example in the original message used min_tx_rate 1, that is why it errored out. So if support means the value 1 and above for min_tx_rate needs to be allowed, then we don’t support it; but we did implement the setting of vf bw in general. See the below functions from i40e and ixgbe: int i40e_ndo_set_vf_bw(struct net_device *netdev, int vf_id, int min_tx_rate, int max_tx_rate) int ixgbe_ndo_set_vf_bw(struct net_device *netdev, int vf, int min_tx_rate, int max_tx_rate)
(In reply to Pragyan Pathi from comment #31) > Per Pavan C's request follow up from our Networking Team - > > Both ixgbe (for Niantic) and i40e (for Fortville) drivers implemented the > set_vf_bw function, but the min_tx_rate can only be the value of 0 for both > drivers. > > The example in the original message used min_tx_rate 1, that is why it > errored out. So if support means the value 1 and above for min_tx_rate needs > to be allowed, then we don’t support it; but we did implement the setting of > vf bw in general. See the below functions from i40e and ixgbe: > > int i40e_ndo_set_vf_bw(struct net_device *netdev, int vf_id, int min_tx_rate, > int max_tx_rate) > > int ixgbe_ndo_set_vf_bw(struct net_device *netdev, int vf, int min_tx_rate, > int max_tx_rate) For above Comment.
To re-phrase: min BW is not supported on intel Niantic and Fortville. But we are enabling it for the NICs that implements it.
Intel ixgbe (for Niantic) and i40e (for Fortville) drivers implemented the set_vf_bw function, but the min_tx_rate can only be the value of 0 for both drivers. The example in the original message used min_tx_rate 1, that is why it errored out. So if support means the value 1 and above for min_tx_rate needs to be allowed, then we don’t support it; but we did implement the setting of vf bw in general. See the below functions from i40e and ixgbe: int i40e_ndo_set_vf_bw(struct net_device *netdev, int vf_id, int min_tx_rate, int max_tx_rate) int ixgbe_ndo_set_vf_bw(struct net_device *netdev, int vf, int min_tx_rate, int max_tx_rate) Franck - Is this targeted for OSP16.0.1? Which z-stream?
Tony, can you share the targeted RHOSP16.0.z version? Pragyan, thanks for confirming that min_tx_rate is not supported for i40e and ixgbe: the only allowed value is zero, meaning this is not implemented.
Hi Frank 16.0.z2 we will be able to work on it.
Feature is VERIFIED on Mellanox ConnectX5, automated test exist in https://github.com/redhat-openstack/nfv-tempest-plugin/blob/devel/nfv_tempest_plugin/tests/scenario/test_nfv_sriov_usecases.py#L264-L288 Verified with core_puddle_version 2020-04-01.3 openstack-neutron-sriov-nic-agent-12.1.1-6.el7ost.noarch
OSP13 support officially ended on 27 June 2023