Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1593637

Summary: Bnxt_en nic: ovs-dpdk-qinq performance was very low
Product: Red Hat Enterprise Linux 7 Reporter: liting <tli>
Component: openvswitchAssignee: Davide Caratti <dcaratti>
Status: CLOSED WONTFIX QA Contact: liting <tli>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.5CC: ajit.khaparde, anantha.subramanyam, atragler, ctrautma, fhallal, gcase, lmreed, ovs-qe, qding, rkhan, tli, tredaelli, vinay.gupta
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-02 08:28:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xena json x2544 profile none

Description liting 2018-06-21 09:35:01 UTC
Description of problem:


Version-Release number of selected component (if applicable):
openvswitch-2.9.0-36.el7fdp.x86_64.rpm

How reproducible:


Steps to Reproduce:
1.Build the ovs topo as following
ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk type=dpdk options:dpdk-devargs=0000:05:00.0 ofport_request=10
ovs-vsctl add-port ovsbr0 dpdk1 -- set Interface dpdk1 type=dpdk type=dpdk options:dpdk-devargs=0000:05:00.1 ofport_request=11
ovs-vsctl add-port ovsbr0 vhost0 -- set interface vhost0 type=dpdkvhostuser ofport_request=20
ovs-vsctl add-port ovsbr0 vhost1 -- set interface vhost1 type=dpdkvhostuser ofport_request=21
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=500000500000
ovs-vsctl --timeout 10 set Interface dpdk0 options:n_rxq=1
ovs-vsctl --timeout 10 set Interface dpdk1 options:n_rxq=1

[root@netqe22 ~]# ovs-vsctl show
48b4f272-8e67-450e-8687-18dd0f74190d
    Bridge "ovsbr0"
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
                options: {dpdk-devargs="0000:07:00.0", n_rxq="1"}
        Port "dpdk1"
            Interface "dpdk1"
                type: dpdk
                options: {dpdk-devargs="0000:07:00.1", n_rxq="1"}
        Port "vhost0"
            Interface "vhost0"
                type: dpdkvhostuser
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vhost1"
            Interface "vhost1"
                type: dpdkvhostuser
    ovs_version: "2.9.0"


2. Added the open flows as following
ovs-ofctl -O OpenFlow13 --timeout 10 del-flows ovsbr0
ovs-ofctl -O OpenFlow13 add-flow ovsbr0 in_port=20,actions=push_vlan:0x88a8,mod_vlan_vid:10,output:10
ovs-ofctl -O OpenFlow13 add-flow ovsbr0 in_port=10,dl_vlan=10,action=pop_vlan,output:20
ovs-ofctl -O OpenFlow13 add-flow ovsbr0 in_port=21,actions=push_vlan:0x88a8,mod_vlan_vid:11,output:11
ovs-ofctl -O OpenFlow13 add-flow ovsbr0 in_port=11,dl_vlan=11,action=pop_vlan,output:21

[root@netqe22 ~]# ovs-ofctl dump-flows ovsbr0
 cookie=0x0, duration=5032.032s, table=0, n_packets=0, n_bytes=0, in_port=vhost0 actions=mod_vlan_vid:10,output:dpdk0
 cookie=0x0, duration=5032.025s, table=0, n_packets=0, n_bytes=0, in_port=vhost1 actions=mod_vlan_vid:11,output:dpdk1
 cookie=0x0, duration=5032.028s, table=0, n_packets=0, n_bytes=0, in_port=dpdk0,dl_vlan=10 actions=strip_vlan,output:vhost0
 cookie=0x0, duration=5032.021s, table=0, n_packets=0, n_bytes=0, in_port=dpdk1,dl_vlan=11 actions=strip_vlan,output:vhost1

3.Inside guest, configured hugepage and bind nic to dpdk. run following testpmd
commands.
testpmd -l 0,1,2 -n4 --socket-mem 1024 -- --burst=64 -i --txqflags=0xf00 --rxd=512 --txd=512 --nb-cores=2 --rxq=1 --txq=1 --disable-hw-vlan --disable-rss --forward-mode=io --auto-start

4.Use Xena script send the traffic

Actual results:
It got about 0.4-1.2mpps. 

Expected results:
Other driver nic got about 5mpps. The bnxt_en nic got lower performance than other driver nics.


Additional info:
The bnxt_en nic info:
[root@netqe22 ~]# ethtool -i p5p1
driver: bnxt_en
version: 1.8.0
firmware-version: 212.0.92.0
expansion-rom-version: 
bus-info: 0000:07:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no

[root@netqe22 ~]# lspci -s 0000:07:00.0
07:00.0 Ethernet controller: Broadcom Limited BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller (rev 01)

Comment 2 Davide Caratti 2018-09-17 09:09:00 UTC
hello Ajit, can you please review this bug?
thank you in advance!

regards,
-- 
davide

Comment 3 Ajit Khaparde 2018-09-17 23:59:37 UTC
Hi Davide,
We are working to repro this. We will update you once we have some info.

Adding Vinay as well.

Thanks
Ajit

Comment 4 vinay.gupta 2018-09-21 21:02:02 UTC
Hi Davide,

I have configured a local setup to repro this issue.
Can you please let me know which Xena script is used to pass the traffic and what parameters to pass/set if any ?

Thanks
Vinay

Comment 5 Christian Trautman 2018-09-24 15:19:31 UTC
Hi Vinay,

Li Ting is on holiday so I took a look at the automation log to determine the setup for you.

We use the XenaVerify script located at -> https://github.com/ctrautma/Xena2544ThroughputVerify

There are instructions on how to install the requirements for executing this script on the github.

I will attach the x2544 json profile used after.

The parameters used on the script were 

python XenaVerify.py -f /mnt/tests/kernel/networking/ovs-dpdk/ovs-dpdk-qinq/xena07_x2544/LiTing.qinq.mesh.bidirectional.x2544 -l 600 -r 10 -t 120

Let me know of any problems using the script.

Comment 6 Christian Trautman 2018-09-24 15:21:34 UTC
Created attachment 1486442 [details]
Xena json x2544 profile

Comment 7 vinay.gupta 2018-09-24 23:38:07 UTC
Hi Christian,

Thanks for providing the script and the 2544 profile.
I tried to run the script but I am getting the following errors:

[root@h081 Xena2544ThroughputVerify]# python XenaVerify.py -f /root/Xena2544ThroughputVerify/LiTing.qinq.mesh.bidirectional.x2544 -l 600 -r 10 -t 120 -d
DEBUG ENABLED!!!
Cannot open assembly 'Xena2544.exe': No such file or directory.
Traceback (most recent call last):
  File "XenaVerify.py", line 631, in <module>
    main(args)
  File "XenaVerify.py", line 406, in main
    result = run_xena(args.save_file_name, args.windows_mode)
  File "XenaVerify.py", line 536, in run_xena
    root = ET.parse(r'./xena2544-report.xml').getroot()
  File "/opt/rh/rh-python34/root/usr/lib64/python3.4/xml/etree/ElementTree.py", line 1187, in parse
    tree.parse(source, parser)
  File "/opt/rh/rh-python34/root/usr/lib64/python3.4/xml/etree/ElementTree.py", line 587, in parse
    source = open(source, "rb")
FileNotFoundError: [Errno 2] No such file or directory: './xena2544-report.xml'

I can workaround the Xena2544.exe and xena2544-report.xml not found error by modifying the script. However, the other errors are still blocking the repro.

Can you please take a look at it ?

Thanks,
Vinay

Comment 8 Christian Trautman 2018-09-25 14:46:10 UTC
You need to pull down the Xena2544.exe file from your xena management system and put it in the same folder you are executing from.  That should resolve the error messages.

Sorry the documentation didn't state that.  I'll update it.

Comment 9 vinay.gupta 2018-09-27 20:56:08 UTC
Thanks Christian.
I got the Xena2544.exe from Xena website and tried to pass the traffic using the command and profile provided. I can see that connection to chassis timed out, I am new to Xena tool so might be missing something here. Here is the error that i am getting:

[root@h081 Xena2544ThroughputVerify]# python XenaVerify.py -f LiTing.qinq.mesh.bidirectional.x2544  -l 600 -r 10 -t 120
INFO: Loading test configuration 2bUsed.x2544
INFO: Activating chassis: 10.19.15.19
ERROR: Connection timed out
ERROR: Connection to chassis '10.19.15.19' failed (timeout).
INFO: Test execution completed
Traceback (most recent call last):
  File "XenaVerify.py", line 631, in <module>
    main(args)
  File "XenaVerify.py", line 406, in main
    result = run_xena(args.save_file_name, args.windows_mode)
  File "XenaVerify.py", line 536, in run_xena
    root = ET.parse(r'./xena2544-report.xml').getroot()
  File "/opt/rh/rh-python34/root/usr/lib64/python3.4/xml/etree/ElementTree.py", line 1187, in parse
    tree.parse(source, parser)
  File "/opt/rh/rh-python34/root/usr/lib64/python3.4/xml/etree/ElementTree.py", line 598, in parse
    self._root = parser._parse_whole(source)
xml.etree.ElementTree.ParseError: no element found: line 1, column 0

Kindly let me know if I am missing some configuration steps with Xena Scripts.

Also, I hooked up my setup to Ixia and passed the traffic (q-in-q frame) instead of using Xena scripts. I do not see .04-1.2 mpps as reported in this bug but I can see a consistent 1.5 mpps, which is still less as compared to the 5mpps requirement. We will work on it and provide an update.

Thanks,
Vinay

Comment 10 Christian Trautman 2018-09-27 21:44:26 UTC
Hi Vinay,

So the profile is tied to our setup.  You would have to create your own x2544 profile to use with your system. To keep the traffic off the bugzilla, please feel free to reach out to me in email to discuss further if you want to pursue the Xena approach. 10.19.15.19 is our Xena chassis so that is why it won't connect.

Comment 11 Marcelo Ricardo Leitner 2019-07-03 15:10:27 UTC
Mass-moving bugs RHEL <= 7.6.0 to 7.7.0.
As we are past RFE deadline for 7.7.0 and we should have no new features on 7.8.0, please evaluate if it's still wanted on RHEL7 and contact PM for exception. You may also move it to RHEL8 if that's wanted. Thanks!

Comment 15 Anantha Subramanyam 2020-09-01 23:27:51 UTC
Per our internal discussion Broadcom is ok to close this old BZ.

Comment 16 Davide Caratti 2020-09-02 08:28:13 UTC
closing as WONTFIX as per comments #14 and #15