RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1546429 - Fast datapath guaranteed bandwidth for SR-IOV, OVS and OVS-DPDK (Test-only)
Summary: Fast datapath guaranteed bandwidth for SR-IOV, OVS and OVS-DPDK (Test-only)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: liting
QA Contact: Hekai Wang
URL:
Whiteboard:
Depends On:
Blocks: 1564988 1624465
TreeView+ depends on / blocked
 
Reported: 2018-02-17 07:37 UTC by Anita Tragler
Modified: 2020-01-21 06:34 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-21 06:33:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:0165 0 None None None 2020-01-21 06:34:09 UTC

Description Anita Tragler 2018-02-17 07:37:02 UTC
Description of requirement:
OVS QoS
http://docs.openvswitch.org/en/latest/howto/qos/
http://docs.openvswitch.org/en/latest/faq/qos/#
OVS already supports ingress policing or rate limiting 

there is no support for queuing, basic token bucket and token bucket size is that of bust size; drop packets if rate exceeded, setting burst size allows algorithm to be more forgiving

For example, the following commands will rate-limit traffic that vif1.0 may generate to 10Mbps:

$ ovs-vsctl set interface vif1.0 ingress_policing_rate=10000 
$ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000

OVS supports egress traffic shaping 
2 queuing options linux-htb or linux-hfsc
specify 
min-rate - Minimum guaranteed bandwidth, in bit/s. 
max rate - Maximum allowed bandwidth, in bit/s.

limit traffic from VM vif1.0 to physical outgoing port eth0 to min-rate 10 Mbps and max-rate 40Mbps; physical port eth0 supports max-rate of 1Gbps

ovs-vsctl -- set Port eth0 qos=@newqos -- \
--id=@newqos create qos type=linux-htb other-config:max-rate=1000000000 queues=0= -- \
--id= create queue other-config:min-rate=10000000 other-config:max-rate=40000000


OVS-DPDK has ingress policing similar to OVS
http://docs.openvswitch.org/en/latest/howto/dpdk/#qos

DPDK Egress policer for 1Mpps
$ ovs-vsctl set port vhost-user0 qos=@newqos -- \
    --id=@newqos create qos type=egress-policer other-config:cir=46000000 \
    other-config:cbs=2048`

Committed Information Rate (CIR) is measured in bytes of IP
              packets per second, i.e. it includes the IP header

SR-IOV VF min and max TX rate, supported with some NICs (Intel ixgbe and Mellanox mlx5)
Bug 1340914 - Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool (RHEL 7.3)
- TX rate must atleast achieve minimum bandwidth but should not exceed max bandwidth
SR-IOV VF max RX rate (policing) not currently supported
https://communities.intel.com/thread/117593

Benchmark ingress rate limiting for OVS and OVS-DPDK 
Test- 4 VMs each vif interface has a ingress rate limit defined of 10Mbps, 10Mbps 100Mbps, 100 Mbps respectively and burst=5Mb,
There is congestion, incoming traffic for each VM exceeds expected ingress rate by double
Verify each VM is receiving allocated rate

Benchmark egress traffic shaping for SR-IOV, OVS  
Test- 4 VMs each vif interface has egress traffic shaping defined; linux-htb or linux-hfsc  with min-rate 10Mbps and max-rate 40Mbps

Verify VMs are able to achieve minimum rate and don't exceed maximum rate
setup testpmd in guest with L2FWD and transmit 100Mbps per VM, verify traffic is shaped to match configuration above

Benchmark egress traffic shaping with egress-policer for OVS-DPDK
Test- 2 VMs each vif interface has egress-policer  for 1 Mpps with cir=46000000, cbs=2048
Verify each VM is able to CIR and minimum packet rate of 1Mpps
setup testpmd in guest with L2FWD and transmit 1.5Mpps per VM, verify traffic is shaped to match configuration above

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 LiLiang 2018-04-28 09:43:24 UTC
I tested :
ovs egress min_rate, max_rate
ovs ingress policing 
sr-iov vf max_tx_rate(as i know, only ixgbe,i40e,qlcnic support this)

they are all work well. By now, no bug was found.

Comment 4 Flavio Leitner 2018-05-08 18:50:12 UTC
Based on comment#3, closing this bug.

Comment 5 Anita Tragler 2018-08-23 14:10:09 UTC
OVS-DPDK has not been tested as yet with egress policer
And we need to verify any performance impact when turning on QoS
See NFV QoS Bandwidth Guarentee EPIC
https://docs.google.com/document/d/1V_fLZgzkyaGwsKaxMFWxt_NP4u9aB72xU3TJleAnL2Q/edit#

Comment 6 liting 2018-09-12 09:09:05 UTC
tested following qos function for dpdk case.
ovs ingress_policing_rate: work well
ovs ingress_policing_burst: did not test the exactly burst function. Just test change the burst number, to see it whether influence the rate, it work well. 
ovs egress cir: work well
ovs egress cbs: did not test the exactly burst function. Just test change the cbs number, to see it whether influence the rate, it work well.
ovs egress linux-htb min_rate, max_rate, ovs dpdk case didn't work, I have open bug1628108
sriov qos, test vf max_tx_rate, work well, just test it on ixgbe nic.

Comment 7 Anita Tragler 2018-09-21 13:32:40 UTC
For OVS-DPDK the ingress rate-limiting or egress policer do not provide any queuing or traffic shaping, so there is no way to do minimum bandwidth guarantee per VM? User can only do Max TX bandwidth per VM with Ingress Rate limiting. Egress policer uses token-bucket mechanism with no support for hierarchical queues based on TX port

OVS QoS supports linux queuing mechanisms linux-htb, linux-hfsc that allows user to create output queues based on TX port and set the min and max bandwidth.

DPDK supports Hierarchical Schduler using Token Bucket metering
RTE Traffic Metering

Traffic metering algorithms:

1. Single Rate Three Color Marker (srTCM): defined by IETF RFC 2697
2. Two Rate Three Color Marker (trTCM): defined by IETF RFC 2698

We need to bring these into OVS-DPDK for traffic shaping usecases, if we want to support minimum bandwidth
RHOSP 14 needs maximum bandwidth and RHOSP15 needs min bandwidth
The usecase is every server has a single 25Gb NIC for all traffic - datapath, storage, control-plane, Management/API
Datapath traffic rate should not be be affected if there is a huge burst of traffic for storage or control plane. A minimum bandwidth should be guaranteed for datapath.

Comment 13 errata-xmlrpc 2020-01-21 06:33:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:0165


Note You need to log in before you can comment on or make changes to this bug.