RE: [PATCH V2] doc: add ice in-tree driver version for Intel NICs
Hi Marchand, Tested platform in this document lists all the platforms including CPU, OS and NIC type with SW package version. We submitted the patch to add our actual tested ice in-tree driver version of E810 NIC in this DPDK release. I think it should be added here. doc/guides/nics/ice.rst is a document for ICE driver introduction. The detailed tested platform information should refer to chapter Tested Platforms/Tested NICs in release notes. And we will make a separate patch to correct typo not relate to ice. Thank you. Yuan. > -Original Message- > From: David Marchand > Sent: Wednesday, October 19, 2022 4:47 PM > To: Jiang, YuX > Cc: dev@dpdk.org; Zhang, Qi Z > Subject: Re: [PATCH V2] doc: add ice in-tree driver version for Intel NICs > > On Fri, Oct 14, 2022 at 9:12 AM Yu Jiang wrote: > > > > doc: add ice in-tree driver version for Intel NICs ice in-tree driver > > test starts from 22.07, cover vf-tso,vf-checksum_offload,vf-rss, > > vf-jumboframe,vm_hotplug etc.. basic vf function. > > > > Signed-off-by: Yu Jiang > > --- > > v2: > > - add detailed commit log > > Quoting original questions: > > """ > - Glad to see Intel is testing with some distribution kernels, but what about > the latest kernel? > """ > > I did not get a reply on this part. > > """ > - It is still unclear which features are checked / working, and which are > missing. > Having such info for this driver in the DPDK documentation would help > everyone. > Do you have a list? > """ > > Thanks for adding some more info in the commitlog. > Please convert this commitlog info into a documentation update (I think > doc/guides/nics/ice.rst is the right place). > This way we will have a detailed list of the supported features with the in- > tree driver, and which feature only work with the out of tree driver. > > > > - correct "out-tree" to "out of tree" > > This is unrelated to ice, please make this change a separate patch. > > > > --- > > > -- > David Marchand
RE: [PATCH] net/ixgbe: enable IPv6 mask for generic flow API
> -Original Message-
> From: Kaiwen Deng
> Sent: Saturday, January 28, 2023 3:15 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Zhou, YidingX ; Deng,
> KaiwenX ; Yang, Qiming
> ; Wu, Wenjun1 ; Zhao1,
> Wei ; Xing, Beilei ; Lu,
> Wenzhuo ; Dai, Wei
> Subject: [PATCH] net/ixgbe: enable IPv6 mask for generic flow API
>
> Add IPv6 addr mask and L4 mask support for rte_flow APIs.
>
> IPv6 flow rules do not take effect in ixgbe when set
> IPv6 addr mask and L4 mask to default value as 0xFF.
>
> Set IPv6 addr mask and L4 mask as 0 to enable fields can fix this issue.
>
> Fixes: 11777435c727 ("net/ixgbe: parse flow director filter")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kaiwen Deng
> ---
Tested-by: Yuan Peng
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Chen, LingliX > Sent: Wednesday, March 22, 2023 1:52 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Peng, Yuan ; Chen, LingliX > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > Signed-off-by: Lingli Chen > --- Reviewed-by: Yuan Peng
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Chen, LingliX > Sent: Wednesday, March 22, 2023 1:52 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Peng, Yuan ; Chen, LingliX > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > Signed-off-by: Lingli Chen Acked-by: Yuan Peng
RE: [PATCH] net/idpf: fix TSO issue
Tested-by: Peng, Yuan
> -Original Message-
> From: Xing, Beilei
> Sent: Wednesday, November 9, 2022 9:18 AM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Peng, Yuan ; Xing, Beilei
>
> Subject: [PATCH] net/idpf: fix TSO issue
>
> From: Beilei Xing
>
> This patch fixes TSO by adding Tx checksum offload.
>
> Fixes: ed5b21acc67e ("net/idpf: support Tx offloading")
>
> Signed-off-by: Beilei Xing
RE: [PATCH] net/idpf: fix memory leak
Tested-by: Peng, Yuan
> -Original Message-
> From: Xing, Beilei
> Sent: Wednesday, November 9, 2022 2:29 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Peng, Yuan ; Xing, Beilei
>
> Subject: [PATCH] net/idpf: fix memory leak
>
> From: Beilei Xing
>
> This patch fixes memory leak during Tx split queue release.
>
> Fixes: 19b58dba9dc3 ("net/idpf: support queue release")
>
> Signed-off-by: Beilei Xing
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
Acked-by: Peng, Yuan > -Original Message- > From: Chen, LingliX > Sent: Thursday, November 17, 2022 12:36 PM > To: Zhang, Qi Z ; dev@dpdk.org > Cc: Peng, Yuan ; Chen, LingliX > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > Add tested Intel platforms with Intel NICs to v22.11 release note. > > Signed-off-by: Lingli Chen > ---
RE: [PATCH] net/idpf: fix port start
Tested-by: Peng, Yuan
> -Original Message-
> From: Xing, Beilei
> Sent: Thursday, November 17, 2022 11:08 AM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Peng, Yuan ; Xing, Beilei
>
> Subject: [PATCH] net/idpf: fix port start
>
> From: Beilei Xing
>
> Port can't start successfully if stopping port and starting port again.
> This patch fixes port start by initialization.
>
> Fixes: e9ff6df15b9a ("net/idpf: stop before closing device")
>
> Signed-off-by: Beilei Xing
> ---
RE: [PATCH v3] net/idpf: fix crash when launching l3fwd
> -Original Message-
> From: Xing, Beilei
> Sent: Friday, November 18, 2022 3:03 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Peng, Yuan ; Xing, Beilei
>
> Subject: [PATCH v3] net/idpf: fix crash when launching l3fwd
>
> From: Beilei Xing
>
> There's core dump when launching l3fwd with 1 queue 1 core. It's because
> NULL pointer is used if fail to configure device.
> This patch removes incorrect check during device configuration, and checks
> NULL pointer when executing VIRTCHNL2_OP_DEALLOC_VECTORS.
>
> Fixes: 549343c25db8 ("net/idpf: support device initialization")
> Fixes: 70675bcc3a57 ("net/idpf: support RSS")
> Fixes: 37291a68fd78 ("net/idpf: support write back based on ITR expire")
>
> Signed-off-by: Beilei Xing
Tested-by: Peng, Yuan
RE: [PATCH] net/idpf: add supported ptypes get
> -Original Message-
> From: Xing, Beilei
> Sent: Friday, November 18, 2022 11:51 AM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Peng, Yuan ; Xing, Beilei
>
> Subject: [PATCH] net/idpf: add supported ptypes get
>
> From: Beilei Xing
>
> Failed to launch l3fwd, the log shows:
> port 0 cannot parse packet type, please add --parse-ptype This patch adds
> dev_supported_ptypes_get ops.
>
> Fixes: 549343c25db8 ("net/idpf: support device initialization")
>
> Signed-off-by: Beilei Xing
Tested-by: Peng, Yuan
Re: [dpdk-dev] [PATCH v7 0/6] Add MACsec offload support for ixgbe
Tested-by: Peng Yuan - version: 17.02-rc1 - OS/Kernel: 4.5.5-300.fc24.x86_64 - GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) - NIC: 82599 Test cases: 5 Passed: 5 Test steps: Test Case 1: MACsec packets send and receive 1. connect the two ixgbe ports with a cable, and bind the two ports to dpdk driver:: ./tools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1 2. config the rx port 1). start the testpmd of rx port:: ./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=rx -w :07:00.1 \ -- --port-topology=chained -i --crc-strip 2). set MACsec offload on:: testpmd>set macsec offload 0 on encrypt on replay-protect on 3). set MACsec parameters as rx_port:: testpmd>set macsec sc rx 0 00:00:00:00:00:01 0 testpmd>set macsec sa rx 0 0 0 0 00112200 4). set MACsec parameters as tx_port:: testpmd>set macsec sc tx 0 00:00:00:00:00:02 0 testpmd>set macsec sa tx 0 0 0 0 00112200 5). set rxonly:: testpmd>set fwd rxonly 6). start:: testpmd>set promisc all on testpmd>start 3. config the tx port 1). start the testpmd of tx port:: ./testpmd -c 0x30 --socket-mem 1024,1024 --file-prefix=tx -w :07:00.0 \ -- --port-topology=chained -i --crc-strip --txqflags=0x0 2). set MACsec offload on:: testpmd>set macsec offload 0 on encrypt on replay-protect on 3). set MACsec parameters as tx_port:: testpmd>set macsec sc tx 0 00:00:00:00:00:01 0 testpmd>set macsec sa tx 0 0 0 0 00112200 4). set MACsec parameters as rx_port:: testpmd>set macsec sc rx 0 00:00:00:00:00:02 0 testpmd>set macsec sa rx 0 0 0 0 00112200 5). set txonly:: testpmd>set fwd txonly 6). start:: testpmd>start 4. check the result:: testpmd>stop testpmd>show port xstats 0 stop the packet transmiting on tx_port first, then stop the packet receiving on rx_port. check the rx data and tx data: tx_good_packets == rx_good_packets out_pkts_encrypted == in_pkts_ok == tx_good_packets == rx_good_packets out_octets_encrypted == in_octets_decrypted out_octets_protected == in_octets_validated if you want to check the content of the packet, use the command:: testpmd>set verbose 1 the received packets are Decrypted. check the ol_flags:PKT_RX_IP_CKSUM_GOOD check the content of the packet: type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP Test Case 2: MACsec packets send and normal receive === 1. disable MACsec offload on rx port:: testpmd>set macsec offload 0 off 2. start the the packets transfer 3. check the result:: testpmd>stop testpmd>show port xstats 0 stop the testpmd on tx_port first, then stop the testpmd on rx_port. the received packets are encrypted. check the content of the packet: type=0x88e5 sw ptype: L2_ETHER - l2_len=14 - Receive queue=0x0 you can't find L3 and L4 infomation in the packet in_octets_decrypted and in_octets_validated doesn't increase on last data transfer. Test Case 3: normal packet send and MACsec receive == 1. enable MACsec offload on rx port:: testpmd>set macsec offload 0 on encrypt on replay-protect on 2. disable MACsec offload on tx port:: testpmd>set macsec offload 0 off 3. start the the packets transfer 4. check the result:: testpmd>stop testpmd>show port xstats 0 stop the testpmd on tx_port first, then stop the testpmd on rx_port. the received packets are not encrypted. check the content of the packet: type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP in_octets_decrypted and out_pkts_encrypted doesn't increase on last data transfer. Test Case 4: MACsec send and receive with wrong parameters == 1. don't add "--txqflags=0x0" in the tx_port command line. the MACsec offload can't work. the tx packets are normal packets. 2. set different pn on rx and tx port, then start the data transfer. 1) set the parameters as test case 1, start and stop the data transfer. check the result, rx port can receive and decrypt the packets normally. 2) reset the pn of tx port to 0:: testpmd>set macsec sa tx 0 0 0 0 00112200 rx port can receive the packets until the pn equals the pn of tx port:: out_pkts_encrypted = in_pkts_late + in_pkts_ok 3. set different keys on rx and tx port, then start the data transfer:: the RX-packets=0, in_octets_decrypted == out_octets_encrypted, in_pkts_notvalid == out_pkts_encrypted, in_pkts_ok=0, rx_good_packets=0 4. set different pi on rx and tx port(reset on rx_port), then start the data transfer:: in_octets_decrypted == out_octets_encrypted, in_pkts_ok = 0, in_pkts_nosci == out_pkts_encrypted 5. set different an on rx and tx port, then start the data transfer::
Re: [dpdk-dev] [PATCH v5 0/8] Add MACsec offload support for ixgbe
Tested-by: Peng Yuan - Tested Branch: master - Tested Commit: eac901ce29be559b1bb5c5da33fe2bf5c0b4bfd6 - OS: Fedora24 4.5.5-300.fc24.x86_64 - GCC: gcc version 5.3.1 20151207 - CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] - Default x86_64-native-linuxapp-gcc configuration - Total 5 cases, 5 passed, 0 failed - Prerequisites: 1x Niantic NIC (2x 10G) 2x IXIA ports (10G) - Added commands: testpmd>set macsec offload (port_id) on encrypt (on|off) replay-protect (on|off) " Enable MACsec offload. " testpmd>set macsec offload (port_id) off " Disable MACsec offload. " testpmd>set macsec sc (tx|rx) (port_id) (mac) (pi) " Configure MACsec secure connection (SC). " testpmd>set macsec sa (tx|rx) (port_id) (idx) (an) (pn) (key) " Configure MACsec secure association (SA). " - Test Case 1: MACsec packets send and receive 1. bind two ports to dpdk driver:: ./tools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1 2. config the rx port 1). start the testpmd of rx port:: ./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=rx -w :07:00.1 \ -- --port-topology=chained -i --crc-strip 2). set MACsec offload on:: testpmd>set macsec offload 0 on encrypt on replay-protect on 3). set MACsec parameters as rx_port:: testpmd>set macsec sc rx 0 00:00:00:00:00:01 0 testpmd>set macsec sa rx 0 0 0 0 00112200 4). set MACsec parameters as tx_port:: testpmd>set macsec sc tx 0 00:00:00:00:00:02 0 testpmd>set macsec sa tx 0 0 0 0 00112200 5). set rxonly:: testpmd>set fwd rxonly 6). start:: testpmd>set promisc all on testpmd>start 3. config the tx port 1). start the testpmd of tx port:: ./testpmd -c 0x30 --socket-mem 1024,1024 --file-prefix=tx -w :07:00.0 \ -- --port-topology=chained -i --crc-strip --txqflags=0x0 2). set MACsec offload on:: testpmd>set macsec offload 0 on encrypt on replay-protect on 3). set MACsec parameters as tx_port:: testpmd>set macsec sc tx 0 00:00:00:00:00:01 0 testpmd>set macsec sa tx 0 0 0 0 00112200 4). set MACsec parameters as rx_port:: testpmd>set macsec sc rx 0 00:00:00:00:00:02 0 testpmd>set macsec sa rx 0 0 0 0 00112200 5). set txonly:: testpmd>set fwd txonly 6). start:: testpmd>start 4. check the result:: testpmd>stop testpmd>show port xstats 0 stop the packet transmiting on tx_port first, then stop the packet receiving on rx_port. check the rx data and tx data: tx_good_packets == rx_good_packets out_pkts_encrypted == in_pkts_ok == tx_good_packets == rx_good_packets out_octets_encrypted == in_octets_decrypted out_octets_protected == in_octets_validated if you want to check the content of the packet, use the command:: testpmd>set verbose 1 the received packets are Decrypted. check the ol_flags:PKT_RX_IP_CKSUM_GOOD check the content of the packet: type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP Test Case 2: MACsec packets send and normal receive === 1. disable MACsec offload on rx port:: testpmd>set macsec offload 0 off 2. start the the packets transfer 3. check the result:: testpmd>stop testpmd>show port xstats 0 stop the testpmd on tx_port first, then stop the testpmd on rx_port. the received packets are encrypted. check the content of the packet: type=0x88e5 sw ptype: L2_ETHER - l2_len=14 - Receive queue=0x0 you can't find L3 and L4 infomation in the packet in_octets_decrypted and in_octets_validated doesn't increase on last data transfer. Test Case 3: normal packet send and MACsec receive == 1. enable MACsec offload on rx port:: testpmd>set macsec offload 0 on encrypt on replay-protect on 2. disable MACsec offload on tx port:: testpmd>set macsec offload 0 off 3. start the the packets transfer 4. check the result:: testpmd>stop testpmd>show port xstats 0 stop the testpmd on tx_port first, then stop the testpmd on rx_port. the received packets are not encrypted. check the content of the packet: type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP in_octets_decrypted and out_pkts_encrypted doesn't increase on last data transfer. Test Case 4: MACsec send and receive with wrong parameters == 1. don't add "--txqflags=0x0" in the tx_port command line. the MACsec offload can't work. the tx packets are normal packets. 2. set different pn on rx and tx port, then start the data transfer. 1) set the parameters as test case 1, start and stop the data transfer. check the result, rx port can receive and decrypt the packets normally. 2) reset the pn of tx port to 0:: t
Re: [dpdk-dev] [PATCH v4 0/5] Support NIC reset and keep same port id
Tested-by: Peng, Yuan - Tested commit bbe569daa7e99b36d44b12bb3d23ddfbc26d383c+the 5 patches. - OS: 4.8.6-300.fc25.x86_64 - GCC: gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G X550T [8086:1563] (rev 01) - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 1cases, 1 passed, 0 failed Steps: DUT: 1. echo 2 >/sys/bus/pci/devices/:83:00.0/sriov_numvfs ./usertools/dpdk-devbind.py -b vfio-pci 83:10.0 83:10.2 ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i 2.testpmd> set verbose 1 testpmd> set fwd mac testpmd> start tester: scapy sendp([Ether(dst="02:09:C0:63:DA:4B")/IP()/UDP()], iface="ens6f0", count=1) dut: testpmd>show port stats all port0 can fwd the packet normally testpmd>show port info all show port number, PCI addr and MAC addr 3. ifconfig ens801f0 down Port 0: Interrupt reset event Port 1: Interrupt reset event ifconfig ens801f0 up 4.testpmd> stop 5. testpmd> port reset all Resetting ports... Finish resetting Port 0 with PCI Address: :83:10.0 Finish resetting Port 1 with PCI Address: :83:10.2 Done 6. testpmd> port stop all Stopping ports... Checking link statuses... Done testpmd> port start all Configuring Port 0 (socket 1) with PCI Address: :83:10.0 Port 0: 02:09:C0:63:DA:4B Configuring Port 1 (socket 1) with PCI Address: :83:10.2 Port 1: 02:09:C0:37:93:6F Checking link statuses... Done 7. testpmd> show port info all confirm same mapping of port id and PCI address. 8.testpmd> start Tester: scapy sendp([Ether(dst="02:09:C0:63:DA:4B")/IP()/UDP()], iface="ens6f0", count=1) dut: testpmd>show port stats all port0 can fwd the packet normally 9.repeat step3 to step8, the same result. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai Sent: Thursday, June 29, 2017 10:58 PM To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, Konstantin ; Zhang, Helin ; Wu, Jingjing ; yuan.pntel@dpdk.org Cc: dev@dpdk.org; Dai, Wei Subject: [dpdk-dev] [PATCH v4 0/5] Support NIC reset and keep same port id Sometimes a port have to be reset. For example PF is reset, all its VF should also be reset. After reset, if the port goes through PCI remove() and then PCI probe() for restoration, its port id may be changed and this is not expected by some customer DPDK application. Normally, PCI probe() includes two parts: one is in rte_ethdev layer and the other is calling PMD dev_init(). PCI remove( ) release all resource allocated from rte_ethdev layer in PCI probe( ) and calls PMD dev_unit( ). To keep same port id and reset the port, only dev_uninit() and dev_init( ) in PMD can be called and keep all resources allocated from rte_ethdev layer poart in PCI probe( ). New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) and then PMD dev_init( ) to reset a port and keep same port id. And then application can go through rte_eth_dev_configure( ), rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and rte_eth_dev_start( ) again to restore its previous settings or to reconfigure itself with different settings. To test this new feature, a testpmd command "port reset port_id" is added. The mapping between port number and its PCI address can be monitored to confirm its port number is kept. And following test case can also be used to confirm the port can work again after reset. A typical test steps are listed as follows: For example, run "ifconfig PF-name down" will trigger a reset to VF. 1. run testpmd with 2 ixgbe VF ports belonging to same PF 2. testpmd > set verbose 1 //to observe VF working 3. testpmd > show port info all //show port number, PCI addr and MAC addr 4. testpmd > start 5. let all ports forwarding work for a while 6. testpmd > show port stats all 7. ifconfig name-of-PF down 8. A message is shown in testmd to indicate PF reset 9. ifconfig name-of-PF up 10. testpmd > stop // stop forwarding to avoid crash during reset 11. testpmd > port reset all 12. testpmd > port stop all 13. testpmd > port start all //recofnig all ports 14. testpmd > show port info all //confirm same mapping of port id and PCI addr 15. testpmd > start // restore forwarding 14. let all ports forwarding work for a while 15. testpmd > show port stats all //confirm all port can work again 16. repeat above step 7 - 15 chagnes: v4: add PCI address to confirm its port number keep same correct test method in cover letter v3: update testpmd command v2: only reset PMD layer resource and keep same port id, but not restore settings Wei Dai (5): ethdev: add support of NIC reset net/ixgbe: add support of reset net/i40e: add support of reset app/testpmd: display PCI address in port info app/testpmd: enhance command to test NIC
Re: [dpdk-dev] [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
Tested-by: Peng, Yuan
- Tested commit bbe569daa7e99b36d44b12bb3d23ddfbc26d383c+the 5 patches.
- OS: 4.8.6-300.fc25.x86_64
- GCC: gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller 10G
X550T [8086:1563] (rev 01)
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1cases, 1 passed, 0 failed
Steps:
DUT:
1. echo 2 >/sys/bus/pci/devices/:83:00.0/sriov_numvfs
./usertools/dpdk-devbind.py -b vfio-pci 83:10.0 83:10.2
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i
2.testpmd> set verbose 1
testpmd> set fwd mac
testpmd> start
tester:
scapy
sendp([Ether(dst="02:09:C0:63:DA:4B")/IP()/UDP()], iface="ens6f0", count=1)
dut:
testpmd>show port stats all
port0 can fwd the packet normally
testpmd>show port info all
show port number, PCI addr and MAC addr
3. ifconfig ens801f0 down
Port 0: Interrupt reset event
Port 1: Interrupt reset event
ifconfig ens801f0 up
4.testpmd> stop
5. testpmd> port reset all
Resetting ports...
Finish resetting Port 0 with PCI Address: :83:10.0 Finish resetting Port 1
with PCI Address: :83:10.2 Done
6. testpmd> port stop all
Stopping ports...
Checking link statuses...
Done
testpmd> port start all
Configuring Port 0 (socket 1) with PCI Address: :83:10.0 Port 0:
02:09:C0:63:DA:4B Configuring Port 1 (socket 1) with PCI Address: :83:10.2
Port 1: 02:09:C0:37:93:6F Checking link statuses...
Done
7. testpmd> show port info all
confirm same mapping of port id and PCI address.
8.testpmd> start
Tester:
scapy
sendp([Ether(dst="02:09:C0:63:DA:4B")/IP()/UDP()], iface="ens6f0", count=1)
dut:
testpmd>show port stats all
port0 can fwd the packet normally
9.repeat step3 to step8, the same result.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
Sent: Thursday, June 29, 2017 10:58 PM
To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
Konstantin ; Zhang, Helin
; Wu, Jingjing ;
yuan.pntel@dpdk.org
Cc: dev@dpdk.org; Dai, Wei
Subject: [dpdk-dev] [PATCH v4 5/5] app/testpmd: enhance command to test NIC
reset
When PF is reset, a message will show it and all its VF need to be reset.
User can run the command "port reset port_id"
to reset the VF port and to keep same port id without any configuration. Then
user can run "port stop port_id"
and "port start port_id" to reconfigure its forwarding mode and parmaters as
previous ones.
To avoid crash, current forwarding should be stopped before running "port reset
port_id".
Signed-off-by: Wei Dai
---
app/test-pmd/cmdline.c | 10 ++---
app/test-pmd/testpmd.c | 61 +++---
app/test-pmd/testpmd.h | 1 +
3 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
ff8ffd2..58ba6e4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -950,6 +950,8 @@ static void cmd_operate_port_parsed(void *parsed_result,
stop_port(RTE_PORT_ALL);
else if (!strcmp(res->name, "close"))
close_port(RTE_PORT_ALL);
+ else if (!strcmp(res->name, "reset"))
+ reset_port(RTE_PORT_ALL);
else
printf("Unknown parameter\n");
}
@@ -959,7 +961,7 @@ cmdline_parse_token_string_t cmd_operate_port_all_cmd =
"port");
cmdline_parse_token_string_t cmd_operate_port_all_port =
TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, name,
- "start#stop#close");
+ "start#stop#close#reset");
cmdline_parse_token_string_t cmd_operate_port_all_all =
TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, value, "all");
@@ -994,6 +996,8 @@ static void cmd_operate_specific_port_parsed(void
*parsed_result,
stop_port(res->value);
else if (!strcmp(res->name, "close"))
close_port(res->value);
+ else if (!strcmp(res->name, "reset"))
+ reset_port(res->value);
else
printf("Unknown parameter\n");
}
@@ -1003,7 +1007,7 @@ cmdline_parse_token_string_t
cmd_operate_specific_port_cmd =
keyword, "port");
cmdline_parse_token_string_t cmd_operate_specific_port_port =
TOKEN_STRING_INITIALIZER(struct cmd_operate_specific_port_result,
- name, "start#stop#close");
+ name, "start#stop#close#reset");
cmdline_parse_token_num_t cmd_
Re: [dpdk-dev] [PATCH v4 2/2] app/test: add unit test for CRC computation
Hi Singh,
The second patch cannot be applied, since the test folder has moved to the DPDK
root directory.
[root@localhost dpdk]# git apply
dpdk-dev-v4-2-2-app-test-add-unit-test-for-CRC-computation.patch
error: app/test/Makefile: No such file or directory
Thank you.
Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jasvinder Singh
Sent: Tuesday, March 21, 2017 3:30 AM
To: dev@dpdk.org
Cc: Doherty, Declan ; De Lara Guarch, Pablo
Subject: [dpdk-dev] [PATCH v4 2/2] app/test: add unit test for CRC computation
This patch provides a set of tests for verifying the functional correctness of
16-bit and 32-bit CRC APIs.
Signed-off-by: Jasvinder Singh
---
app/test/Makefile | 2 +
app/test/test_crc.c | 223
2 files changed, 225 insertions(+)
create mode 100644 app/test/test_crc.c
diff --git a/app/test/Makefile b/app/test/Makefile index 1a5e03d..2a497f7 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -160,6 +160,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_cirbuf.c
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_string.c
SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += test_cmdline_lib.c
+SRCS-$(CONFIG_RTE_LIBRTE_NET) += test_crc.c
+
ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y)
SRCS-y += test_red.c
SRCS-y += test_sched.c
diff --git a/app/test/test_crc.c b/app/test/test_crc.c new file mode 100644
index 000..2eb0bff
--- /dev/null
+++ b/app/test/test_crc.c
@@ -0,0 +1,223 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Corporation.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+#include "test.h"
+
+#define CRC_VEC_LEN32
+#define CRC32_VEC_LEN1 1512
+#define CRC32_VEC_LEN2 348
+#define CRC16_VEC_LEN1 12
+#define CRC16_VEC_LEN2 2
+#define LINE_LEN 75
+
+/* CRC test vector */
+static const uint8_t crc_vec[CRC_VEC_LEN] = {
+ '0', '1', '2', '3', '4', '5', '6', '7',
+ '8', '9', 'a', 'b', 'c', 'd', 'e', 'f',
+ 'g', 'h', 'i', 'j', 'A', 'B', 'C', 'D',
+ 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', };
+
+/* 32-bit CRC test vector */
+static const uint8_t crc32_vec1[12] = {
+ 0xBE, 0xD7, 0x23, 0x47, 0x6B, 0x8F,
+ 0xB3, 0x14, 0x5E, 0xFB, 0x35, 0x59,
+};
+
+/* 16-bit CRC test vector 1*/
+static const uint8_t crc16_vec1[CRC16_VEC_LEN1] = {
+ 0x0D, 0x01, 0x01, 0x23, 0x45, 0x67,
+ 0x89, 0x01, 0x23, 0x45, 0x00, 0x01,
+};
+
+/* 16-bit CRC test vector 2*/
+static const uint8_t crc16_vec2[CRC16_VEC_LEN2] = {
+ 0x03, 0x3f,
+};
+/** CRC results */
+uint32_t crc32_vec_res, crc32_vec1_res, crc32_vec2_res; uint32_t
+crc16_vec_res, crc16_vec1_res, crc16_vec2_res;
+
+static int
+crc_calc(const uint8_t *vec,
+ uint32_t vec_len,
+ enum rte_net_crc_type type)
+{
+ /* compute CRC */
+ uint32_t ret = rte_net_crc_calc(vec, vec_len, type);
+
+ /* dump data on console*/
+ rte_hexdump(stdout, NULL, vec, vec_len);
+
+ return ret;
+}
+
+static void
+crc_calc_scalar(void)
+{
+ uint32_t i;
+ enum rte_net_crc_type type;
+ uint8_t *test_data;
+
+ /* 32-bit ethernet CRC: scalar result */
+ type = RTE_NET_CRC32_ETH;
+ crc32_vec_res = crc_calc(crc_vec,
+ CRC_VEC_LEN,
+
Re: [dpdk-dev] [PATCH] net/i40e: fix flow director for IPv6
Tested-by: Peng, Yuan
- Tested Branch: dpdk-next-crypto/master
- Tested commit 18872f511c17a0a3591d4bfa5d56eefa5b85339c+7patches+this patch
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1583]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1cases, 1 passed, 0 failed
Steps:
DUT:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0
./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -w 05:00.0
--file-prefix=pf --socket-mem=1024,1024 -- -i --rxq=16 --txq=16 --disable-rss
--pkt-filter-mode=perfect
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
testpmd> flow create 0 ingress pattern eth / vlan tci is 1 / ipv6 src is
2001::1 dst is 2001::2 tc is 1 proto is 5 hop is 10 / end actions queue index 1
/ end
Flow rule #0 created
tester:
scapy
pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1Q(vlan=1)/IPv6(src="2001::1",
dst="2001::2", tc=1, nh=5, hlim=10)/Raw('x' * 20)
DUT:
testpmd> port 0/queue 1: received 1 packets
src=00:00:00:00:00:00 - dst=00:11:22:33:44:55 - type=0x86dd - length=74 -
nb_segs=1 - FDIR matched hash=0x0 ID=0x0 - VLAN tci=0x1 - hw ptype: L2_ETHER
L3_IPV6_EXT_UNKNOWN L4_NONFRAG - sw ptype: L2_ETHER L3_IPV6 - l2_len=14 -
l3_len=40 - Receive queue=0x1
ol_flags: PKT_RX_VLAN_PKT PKT_RX_FDIR PKT_RX_L4_CKSUM_GOOD
PKT_RX_IP_CKSUM_GOOD PKT_RX_VLAN_STRIPPED
pkt1 to queue 1, the bug fixed.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Beilei Xing
Sent: Thursday, June 22, 2017 5:31 PM
To: Wu, Jingjing
Cc: dev@dpdk.org; sta...@dpdk.org
Subject: [dpdk-dev] [PATCH] net/i40e: fix flow director for IPv6
After adding a fdir rule for IPv6 with input set TC, IPv6 packets with the
specific TC can't be assigned the right queue.
The root cause is that TC is parsed wrongly, this patch fixes TC parsing
problem.
Fixes: 7d83c152a207 ("net/i40e: parse flow director filter")
Cc: sta...@dpdk.org
Signed-off-by: Beilei Xing
---
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_fdir.c | 1 -
drivers/net/i40e/i40e_flow.c | 14 --
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 05ecd27..80f9504 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -448,6 +448,7 @@ struct i40e_vmdq_info {
I40E_PRTQF_FLX_PIT_DEST_OFF_MASK))
#define I40E_WORD(hi, lo) (uint16_t)hi) << 8) & 0xFF00) | ((lo) & 0xFF))
#define I40E_FLEX_WORD_MASK(off) (0x80 >> (off))
+#define I40E_FDIR_IPv6_TC_OFFSET 20
/*
* Structure to store flex pit for flow diretor.
diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c index
a970b56..8013add 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -67,7 +67,6 @@
#define I40E_FDIR_IP_DEFAULT_VERSION_IHL0x45
#define I40E_FDIR_TCP_DEFAULT_DATAOFF 0x50
#define I40E_FDIR_IPv6_DEFAULT_VTC_FLOW 0x6000
-#define I40E_FDIR_IPv6_TC_OFFSET20
#define I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS 0xFF
#define I40E_FDIR_IPv6_PAYLOAD_LEN 380
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c index
c7589ce..1a27572 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -52,8 +52,7 @@
#include "base/i40e_prototype.h"
#include "i40e_ethdev.h"
-#define I40E_IPV4_TC_SHIFT 4
-#define I40E_IPV6_TC_MASK (0x00FF << I40E_IPV4_TC_SHIFT)
+#define I40E_IPV6_TC_MASK (0xFF << I40E_FDIR_IPv6_TC_OFFSET)
#define I40E_IPV6_FRAG_HEADER 44
#define I40E_TENANT_ARRAY_NUM 3
#define I40E_TCI_MASK 0x
@@ -2352,6 +2351,7 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
bool cfg_flex_msk = true;
uint16_t outer_tpid;
uint16_t ether_type;
+ uint32_t vtc_flow_cpu;
int ret;
memset(off_arr, 0, I40E_MAX_FLXPLD_FIED); @@ -2508,8 +2508,8 @@
i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
input_set |= I40E_INSET_IPV6_DST;
if ((ipv6_mask->hdr.vtc_flow &
-rte_cpu_to_be_16(I40E_IPV6_TC_MASK))
- == rte_cpu_to_be_16(I40E_IPV6_TC_MASK))
+rte_cpu_to_be_32(I40E_IPV6_TC_MASK))
+ == rte_cpu_to_be_32(I40E_IPV6_TC_MASK))
input_set |= I40E_INSET_IPV6_TC;
if (ipv6_mask->hdr.proto == UINT8_MAX)
input_set |= I40E_INSET_IPV6_NEXT_HDR;
@@ -2517,9 +2517,11 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *
Re: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
Tested-by: Peng, Yuan
- Tested commit c1923afc0999b5b6f109190bc5b69b6c3d334635+the 5 patches.
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection [8086:10fb] (rev 01)
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1cases, 1 passed, 0 failed
Steps:
DUT:
1. run testpmd with ixgbe VF
echo 1 >/sys/bus/pci/devices/:07:00.0/sriov_numvfs
ip link set ens786f0 vf 0 mac 00:11:22:33:44:11
./usertools/dpdk-devbind.py -b vfio-pci 07:10.0
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i
2. testpmd > set verbose 1
testpmd> set fwd rxonly
testpmd> start
tester:
scapy
>>> pkt1 = Ether(dst="00:11:22:33:44:11")/IP()/UDP()/Raw('x' * 20)
>>> sendp(pkt1, iface="ens786f1", count=1)
Vf can receive the packet correctly.
3. ifconfig ens786f0 down
A message is shown in testmd to indicate PF reset:
Port 0: Interrupt reset event
4. ifconfig ens786f0 up
5. testpmd > stop
6. testpmd > reset_port 0
7. testpmd> reconfig_port 0
PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip
Port 0 MAC: 00 11 22 33 44 11
Begin to forward at least 100 packets to test reconfiguration
8. tester:
>>> sendp(pkt1, iface="ens786f1", count=100)
9. Finish forwarding 100 packets to test reconfiguration
testpmd> show port stats all
NIC statistics for port 0
RX-packets: 100RX-missed: 0 RX-bytes: 6200
RX-errors: 0
RX-nombuf: 0
TX-packets: 0 TX-errors: 0 TX-bytes: 0
Throughput (since last show)
Rx-pps:0
Tx-pps:0
The vf can be reconfigured successfully after pf reset.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
Sent: Tuesday, June 27, 2017 10:07 PM
To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
Konstantin ; Zhang, Helin
; Wu, Jingjing
Cc: dev@dpdk.org; Dai, Wei
Subject: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
Sometimes a port have to be reset. After reset, if the port goes through PCI
remove() and then PCI probe() for restoration, its port id may be changed and
this is not expected by some customer DPDK application.
Normally, PCI probe() includes two parts: one is in rte_ethdev layer and the
other is calling PMD dev_init(). PCI remove( ) release all resource allocated
from rte_ethdev layer in PCI probe( ) and calls PMD dev_unit( ).
To keep same port id and reset the port, only dev_uninit() and dev_init( ) in
PMD can be called and keep all resources allocated from rte_ethdev layer poart
in PCI probe( ).
New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) and then
PMD dev_init( ) to reset a port and keep same port id.
And then application can go through rte_eth_dev_configure( ),
rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and rte_eth_dev_start( )
again to restore its previous settings or to reconfigure itself with different
settings.
To test this new feature, 2 testpmd commands are introduced.
The first command "reset_port port_id" calls rte_eth_dev_reset( ).
The second command "reconfig_port port_id" is used to test if the port can be
reconfigured successfully. This command configure the port with the simplest
settings include only 1 Rx queue, only 1 Tx queue, Rx mode = None and Tx mode =
None. It check port by receving at least
100 packets and then forward these packets from itself.
A typical test steps are listed as follows:
For example, run "ifconfig PF-name down" will trigger a reset to its VF.
1. run testpmd with ixgbe vF
2. testpmd > set verbose 1 //to observe VF working 3. ifconfig name-of-PF down
4. A message is shown in testmd to indicate PF reset 5. ifconfig name-of-PF up
6. testpmd > stop // stop forwarding to avoid crash during reset 7. testpmd >
reset_port port_id_of_VF 8. testpmd > reconfig_port port_id_of_VF
Wei Dai (5):
ethdev: add support of NIC reset
net/ixgbe: add support of reset
net/i40e: add support of reset
app/testpmd: add command to test NIC reset
app/testpmd: add command to test NIC restoration
app/test-pmd/cmdline.c | 62 ++
app/test-pmd/config.c | 111 +
app/test-pmd/testpmd.h | 2 +
drivers/net/i40e/i40e_ethdev.c | 16 +
drivers/net/i40e/i40e_ethdev_vf.c | 16 +
drivers/net/ixgbe/ixgbe_ethdev.c | 38 +++
lib/librte_ether/rte_ethdev.c | 17 +
lib/librte_ether/rte_ethdev.h | 12
lib/librte_ether/rte_ether_version.map | 2 +-
9 files changed, 275 insertions(+), 1 deletion(-)
--
2.7.4
Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29
Tested-by: Peng Yuan - Tested Branch: dpdk v17.02 - Tested Commit: b9ebab26d98f61bc407572623c4bee4390a8b432 - OS: 4.4.26-yocto-standard - IFWI: HAVLCRB1.X64.0014.D76.1703170116 - NIC: Intel Corporation Device [8086:15ce] (rev 10) driver: ixgbe-5.0.7 firmware-version: 0x86f8/ 0x8714 - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 69 cases, 69 passed, 0 failed You can check the test report from attachment. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai Sent: Tuesday, April 18, 2017 2:57 PM To: Zhang, Helin ; Ananyev, Konstantin ; Lu, Wenzhuo Cc: dev@dpdk.org; Dai, Wei Subject: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29 This patch set has following 4 patches. No any new device id is added. net/ixgbe/base: acquire PHY semaphore before device reset net/ixgbe/base: add support for 2.5G KX physical layer net/ixgbe/base: add MAC X550em/X557 LED on/off support net/ixgbe/base: update base driver version to 2017.03.29 drivers/net/ixgbe/base/README| 2 +- drivers/net/ixgbe/base/ixgbe_82598.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_82598.h | 2 +- drivers/net/ixgbe/base/ixgbe_82599.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_82599.h | 2 +- drivers/net/ixgbe/base/ixgbe_api.c | 2 +- drivers/net/ixgbe/base/ixgbe_api.h | 2 +- drivers/net/ixgbe/base/ixgbe_phy.c | 4 ++-- drivers/net/ixgbe/base/ixgbe_phy.h | 2 +- drivers/net/ixgbe/base/ixgbe_type.h | 37 ++-- drivers/net/ixgbe/base/ixgbe_x540.c | 12 ++-- drivers/net/ixgbe/base/ixgbe_x540.h | 2 +- drivers/net/ixgbe/base/ixgbe_x550.c | 33 drivers/net/ixgbe/base/ixgbe_x550.h | 2 +- 14 files changed, 72 insertions(+), 38 deletions(-) -- 2.7.4
[dpdk-dev] a doubt about rss types action in rte_flow
Hi Adrien, I have a doubt about the action rss types in rte_flow. testpmd> flow create 0 ingress pattern end actions rss types end / end what is the expected function of the command? Does it mean enable RSS in no types? So actually it can disable rss all? There are different execution result of the command from our different NICs. Some NICs report error: Caught error type 2 (flow rule (handle)): Failed to create flow.: Invalid argument With some NICs, the command can be executed successfully, and disable rss function for all packet types. Could you help to solve my questions? Thank you. Yuan.
Re: [dpdk-dev] [PATCH] net/ixgbe: fix RSS flow return error
Tested-by: Peng, Yuan
- Tested Branch: master
- Tested Commit: 739e13bcc98f562d3301f808ec76507ebae82e63
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection
[8086:10fb] (rev 01)
Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev
01)
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1
1. Start the testpmd::
./testpmd -c 1 -n 4 -- -i --nb-cores=8 --rxq=4 --txq=4
--port-topology=chained
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
2. Show port default RSS fuctions::
testpmd> show port 0 rss-hash
RSS functions:
ipv4-frag ipv4-other ipv6-frag ipv6-other ip
Send the ipv4-other packets with different src/dst ip address.
All the packets are distributed to all the four queues.
3. disable all RSS fuctions::
testpmd> flow create 0 ingress pattern end actions rss types none end / end
Flow rule #0 created
testpmd> show port 0 rss-hash
RSS disabled
Send the ipv4-udp packets with different src/dst ip address.
All the packets are distributed to queue 0.
Notes: only i40e support the command,
others don't support the command created.
4. enable RSS fuction with all RSS hash type::
testpmd> flow create 0 ingress pattern end actions rss types all end / end
Flow rule #1 created
testpmd> show port 0 rss-hash
RSS functions:
all ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other ipv6-frag ipv6-tcp
ipv6-udp ipv6-sctp ipv6-other l2-payload ip udp tcp sctp
Send the ipv4-udp packets with different src/dst ip address.
All the packets are distributed to all the four queues.
-Original Message-
From: Zhao1, Wei
Sent: Tuesday, October 23, 2018 11:38 AM
To: dev@dpdk.org
Cc: Zhang, Qi Z ; sta...@dpdk.org; Peng, Yuan
; Zhao1, Wei
Subject: [PATCH] net/ixgbe: fix RSS flow return error
If hash function is 0, it should disable RSS then return 0.
Fixes: 518cc3927b13 ("net/ixgbe: move RSS to flow API")
Signed-off-by: Wei Zhao
---
drivers/net/ixgbe/ixgbe_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index ae21f04..ad9c46d 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -5703,7 +5703,7 @@ ixgbe_config_rss_filter(struct rte_eth_dev *dev,
*/
if ((rss_conf.rss_hf & IXGBE_RSS_OFFLOAD_ALL) == 0) {
ixgbe_rss_disable(dev);
- return -EINVAL;
+ return 0;
}
if (rss_conf.rss_key == NULL)
rss_conf.rss_key = rss_intel_key; /* Default hash key */
--
2.7.5
Re: [dpdk-dev] [PATCH] app/testpmd: support more types for flow RSS
Tested-by: Peng, Yuan
- Tested Branch: master
- Tested Commit: 739e13bcc98f562d3301f808ec76507ebae82e63
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection
[8086:10fb] (rev 01)
Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev
01)
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1 1. Start the testpmd::
./testpmd -c 1 -n 4 -- -i --nb-cores=8 --rxq=4 --txq=4
--port-topology=chained
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
2. Show port default RSS fuctions::
testpmd> show port 0 rss-hash
RSS functions:
ipv4-frag ipv4-other ipv6-frag ipv6-other ip
Send the ipv4-other packets with different src/dst ip address.
All the packets are distributed to all the four queues.
3. disable all RSS fuctions::
testpmd> flow create 0 ingress pattern end actions rss types none end / end
Flow rule #0 created
testpmd> show port 0 rss-hash
RSS disabled
Send the ipv4-udp packets with different src/dst ip address.
All the packets are distributed to queue 0.
Notes: only i40e support the command,
others don't support the command created.
4. enable RSS fuction with all RSS hash type::
testpmd> flow create 0 ingress pattern end actions rss types all end / end
Flow rule #1 created
testpmd> show port 0 rss-hash
RSS functions:
all ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other ipv6-frag ipv6-tcp
ipv6-udp ipv6-sctp ipv6-other l2-payload ip udp tcp sctp
Send the ipv4-udp packets with different src/dst ip address.
All the packets are distributed to all the four queues.
-Original Message-
From: Zhao1, Wei
Sent: Monday, October 22, 2018 3:49 PM
To: dev@dpdk.org
Cc: Zhang, Qi Z ; sta...@dpdk.org; Peng, Yuan
; Zhao1, Wei
Subject: [PATCH] app/testpmd: support more types for flow RSS
Some user and tester require flow RSS to support more types, so and "all" and
"none" to make configuration more easy for users.
Signed-off-by: Wei Zhao
---
app/test-pmd/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
bf3cd0a..f068da1 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -74,6 +74,10 @@ static const struct { };
const struct rss_type_info rss_type_table[] = {
+ { "all", ETH_RSS_IP | ETH_RSS_TCP |
+ ETH_RSS_UDP | ETH_RSS_SCTP |
+ ETH_RSS_L2_PAYLOAD },
+ { "none", 0 },
{ "ipv4", ETH_RSS_IPV4 },
{ "ipv4-frag", ETH_RSS_FRAG_IPV4 },
{ "ipv4-tcp", ETH_RSS_NONFRAG_IPV4_TCP },
--
2.7.5
Re: [dpdk-dev] [PATCH] app/testpmd: fix Rx offload search error
Tested-by: Peng, Yuan
- Tested Branch: master
- Tested Commit: c59b06294fb4531792a4c74ca63fa79a4cb53457
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection
[8086:10fb] (rev 01)
Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev
01)
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 - -i --rxq=4 --txq=4
testpmd> show port 0 rx_offload capabilities
Rx Offloading Capabilities of port 0 :
Per Queue : VLAN_STRIP
Per Port : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
testpmd> show port 0 rx_offload configuration
Rx Offloading Configuration of port 0 :
Port :
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
testpmd> port stop 0
testpmd> port config 0 rx_offload security on
testpmd> port config 0 rx_offload scatter on
testpmd> port config 0 rx_offload keep_crc on
testpmd> port config 0 rx_offload jumbo_frame on
testpmd> port config 0 rx_offload vlan_extend on
testpmd> port config 0 rx_offload vlan_filter on
testpmd> port config 0 rx_offload macsec_strip on
testpmd> port config 0 rx_offload tcp_lro on
testpmd> port config 0 rx_offload tcp_cksum on
testpmd> port config 0 rx_offload udp_cksum on
testpmd> port config 0 rx_offload ipv4_cksum on
testpmd>
testpmd> show port 0 rx_offload configuration
Rx Offloading Configuration of port 0 :
Port : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
Queue[ 0] : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
Queue[ 1] : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
Queue[ 2] : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
Queue[ 3] : IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO MACSEC_STRIP VLAN_FILTER
VLAN_EXTEND JUMBO_FRAME SCATTER SECURITY KEEP_CRC
testpmd> port config 0 rx_offload ipv4_cksum off
testpmd> port config 0 rx_offload udp_cksum off
testpmd> port config 0 rx_offload tcp_cksum off
testpmd> port config 0 rx_offload tcp_lro off
testpmd> port config 0 rx_offload macsec_strip off
testpmd> port config 0 rx_offload vlan_filter off
testpmd> port config 0 rx_offload vlan_extend off
testpmd> port config 0 rx_offload jumbo_frame off
testpmd> port config 0 rx_offload keep_crc off
testpmd> port config 0 rx_offload scatter off
testpmd> port config 0 rx_offload security off
testpmd> show port 0 rx_offload configuration
Rx Offloading Configuration of port 0 :
Port :
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
All the capabilities can be configured successfully.
The case can pass with i40e and ixgbe card.
-Original Message-
From: Zhao1, Wei
Sent: Wednesday, November 7, 2018 2:14 PM
To: dev@dpdk.org
Cc: sta...@dpdk.org; Peng, Yuan ; Lu, Wenzhuo
; Zhao1, Wei
Subject: [PATCH] app/testpmd: fix Rx offload search error
There is an error in function in function search_rx_offload(), it will break
when get unexpected return value from function rte_eth_dev_rx_offload_name(),
but rte_eth_dev_rx_offload_name() will return some unexpected value indead.
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Signed-off-by: Wei Zhao
---
app/test-pmd/cmdline.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
5e08a1b..1275074 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -17805,10 +17805,7 @@ search_rx_offload(const char *name)
if (!strcasecmp(single_name, name)) {
found = 1;
break;
- } else if (!strcasecmp(single_name, "UNKNOWN"))
- break;
- else if (single_name == NULL)
- break;
+ }
single_offload <<= 1;
}
--
2.7.5
Re: [dpdk-dev] FW: [PATCH] net/i40e: add parameter check for RSS flow init
Hi, Adrien Mazarguil
Yes. It's just the problem related to commit
a4391f8bae85db0153e1f101c21c61151573baad "app/testpmd: set default RSS key as
null".
You can check the detailed bug information from
https://jira01.devtools.intel.com/browse/DPDK-7136?filter=-2
Thank you.
Yuan.
-Original Message-
From: Zhao1, Wei
Sent: Tuesday, November 13, 2018 9:29 AM
To: Adrien Mazarguil
Cc: Peng, Yuan ; dev@dpdk.org
Subject: RE: FW: [PATCH] net/i40e: add parameter check for RSS flow init
Hi, Adrien Mazarguil
Peng yuan has find this problem, if you use the following test step,
You will find the problem.
./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 - -i --nb-cores=8
--rxq=4 --txq=4 --port-topology=chained ...
testpmd> start
testpmd> flow create 0 ingress pattern end actions rss types ipv4-udp
testpmd> end key 67108863 / end
Segmentation fault (core dumped)
https://patches.dpdk.org/patch/47995/
This is the protection I have add, but you still need fix some bug in rte_flow
CLI.
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com]
> Sent: Monday, November 12, 2018 10:03 PM
> To: Zhao1, Wei
> Cc: Peng, Yuan
> Subject: Re: FW: [PATCH] net/i40e: add parameter check for RSS flow init
>
> Hi Wei,
>
> On Mon, Nov 12, 2018 at 10:02:20AM +, Zhao1, Wei wrote:
> > Hi, adrien.mazarguil
> >
> >There is some error in CML layer for config this parameter, in
> > i40e PMD it will get NULL of in->key even if tester config Some specific
> > key
> from testpmd CLI, I add some protection but you also need fix that bug in CLI
> layer.
>
> Odd, is that new? You shouldn't need to worry about the pointer if key_len is
> zero.
>
> Isn't this problem related to commit a4391f8bae85 "app/testpmd: set default
> RSS key as null"? There's an ongoing discussion to revert this patch [1].
testpmd> flow create 0 ingress pattern end actions rss types ipv4-udp end key
67108863 / end
This CLI command key is not NLLL, but i40E PMD get NULL.
> [1] https://mails.dpdk.org/archives/dev/2018-November/118633.html
>
> > > -Original Message-
> > > From: Zhao1, Wei
> > > Sent: Monday, November 12, 2018 5:25 PM
> > > To: dev@dpdk.org
> > > Cc: Zhang, Qi Z ; sta...@dpdk.org; Peng, Yuan
> > > ; Zhao1, Wei
> > > Subject: [PATCH] net/i40e: add parameter check for RSS flow init
> > >
> > > There need an parameter check for RSS flow init, or it may cause
> > > core dump if pointer is NULL in memory copy.
> > >
> > > Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow
> > > API")
> > >
> > > Signed-off-by: Wei Zhao
> > > ---
> > > drivers/net/i40e/i40e_ethdev.c | 5 -
> > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > b/drivers/net/i40e/i40e_ethdev.c index 1c77906..217a8dc 100644
> > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > @@ -12552,13 +12552,16 @@ i40e_rss_conf_init(struct
> > > i40e_rte_flow_rss_conf *out,
> > > if (in->key_len > RTE_DIM(out->key) ||
> > > in->queue_num > RTE_DIM(out->queue))
> > > return -EINVAL;
> > > + if (!in->key && in->key_len)
> > > + return -EINVAL;
> > > + if (out->key && in->key)
> > > + out->conf.key = memcpy(out->key, in->key, in->key_len);
> > > out->conf = (struct rte_flow_action_rss){
> > > .func = in->func,
> > > .level = in->level,
> > > .types = in->types,
> > > .key_len = in->key_len,
> > > .queue_num = in->queue_num,
> > > - .key = memcpy(out->key, in->key, in->key_len),
> > > .queue = memcpy(out->queue, in->queue,
> > > sizeof(*in->queue) * in->queue_num),
> > > };
> > > --
> > > 2.7.5
> >
>
> --
> Adrien Mazarguil
> 6WIND
[dpdk-dev] Recall: FW: [PATCH] net/i40e: add parameter check for RSS flow init
Peng, Yuan would like to recall the message, "FW: [PATCH] net/i40e: add parameter check for RSS flow init".
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Tested-by: Peng, Yuan
- DPDK version: 18.08-rc1 commit c27dbc300eee78c2eb33e84181617fdd7cbaaae4
- OS: 4.5.5-300.fc24.x86_64
- Compiler: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- Hardware platform: BDE-EP
- NIC Intel Corporation Device Fortville [8086:1583]
- driver: i40e
- version: 2.4.3
- firmware-version: 6.01 0x80003205 1.1691.0
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 2 cases, 2 passed, 0 failed
Test1:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1
1../x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 - -i --rxq=4 --txq=4
testpmd> show port 0 rx_offload capabilities
Rx Offloading Capabilities of port 0 :
Per Queue :
Per Port : VLAN_STRIP IPV4_CKSUM UDP_CKSUM TCP_CKSUM QINQ_STRIP
OUTER_IPV4_CKSUM VLAN_FILTER VLAN_EXTEND JUMBO_FRAME CRC_STRIP KEEP_CRC
testpmd> show port 0 rx_offload configuration
Rx Offloading Configuration of port 0 :
Port :
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
Testpmd> port stop 0
testpmd> port config 0 rx_offload keep_crc on
testpmd> port start 0
The port can be started normally.
Test2:
1. Start testpmd and get the tx_offload capability and configuration::
./testpmd -c f -n 4 -- -i --rxq=4 --txq=4
testpmd> show port 0 tx_offload capabilities
Tx Offloading Capabilities of port 0 :
Per Queue : MBUF_FAST_FREE
Per Port : VLAN_INSERT IPV4_CKSUM UDP_CKSUM TCP_CKSUM SCTP_CKSUM TCP_TSO
OUTER_IPV4_CKSUM QINQ_INSERT VXLAN_TNL_TSO GRE_TNL_TSO IPIP_TNL_TSO
GENEVE_TNL_TSO MULTI_SEGS
testpmd> show port 0 tx_offload configuration
Tx Offloading Configuration of port 0 :
Port : MBUF_FAST_FREE
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
2. Disable mbuf_fast_free per_port::
testpmd> port stop 0
testpmd> port config 0 tx_offload mbuf_fast_free off
testpmd> port start 0
testpmd> show port 0 tx_offload configuration
Tx Offloading Configuration of port 0 :
Port :
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
3. Enable mbuf_fast_free per_queue::
testpmd> port 0 txq 0 tx_offload mbuf_fast_free on
testpmd> port 0 txq 1 tx_offload mbuf_fast_free on
testpmd> port 0 txq 2 tx_offload mbuf_fast_free on
testpmd> port 0 txq 3 tx_offload mbuf_fast_free on
testpmd> port start 0
testpmd> show port 0 tx_offload configuration
Tx Offloading Configuration of port 0 :
Port :
Queue[ 0] : MBUF_FAST_FREE
Queue[ 1] : MBUF_FAST_FREE
Queue[ 2] : MBUF_FAST_FREE
Queue[ 3] : MBUF_FAST_FREE
4. Disable mbuf_fast_free per_queue::
testpmd> port 0 txq 0 tx_offload mbuf_fast_free off
testpmd> port 0 txq 1 tx_offload mbuf_fast_free off
testpmd> port 0 txq 2 tx_offload mbuf_fast_free off
testpmd> port 0 txq 3 tx_offload mbuf_fast_free off
testpmd> port start 0
testpmd> show port 0 tx_offload configuration
Tx Offloading Configuration of port 0 :
Port :
Queue[ 0] :
Queue[ 1] :
Queue[ 2] :
Queue[ 3] :
The mbuf_fast_free per_queue can be set normally.
-Original Message-
From: Dai, Wei
Sent: Friday, July 20, 2018 10:43 AM
To: Wu, Jingjing ; Peng, Yuan
Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
Subject: [PATCH] app/testpmd: fix commands to config some offload
Without this patch, testpmd command to config Rx offload keep_crc would fail
and report "Bad argument".
This patch aslo fix the command to config the Tx offload mbuf_fast_free.
Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
---
app/test-pmd/cmdline.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
5885289..a0ed3a0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -16665,7 +16665,7 @@ struct cmd_config_per_port_rx_offload_result {
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security");
+ "crc_strip#scatter#timestamp#security#keep_crc");
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -16744,7 +16744,7 @@ struct cmd_config_per_port_rx_offload_result {
.help_str = "port config rx_offload vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
Sent: Tuesday, July 24, 2018 11:45 AM
To: Wu, Jingjing ; Lu, Wenzhuo ;
dev@dpdk.org
Cc: Dai, Wei ; sta...@dpdk.org
Subject: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Without this patch, testpmd command to config Rx offload keep_crc would fail
and report "Bad argument".
This patch aslo fix the command to config the Tx offload mbuf_fast_free.
Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Tested-by: Peng, Yuan
- DPDK version: 18.08-rc1 commit c27dbc300eee78c2eb33e84181617fdd7cbaaae4
- OS: 4.5.5-300.fc24.x86_64
- Compiler: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- Hardware platform: BDE-EP
- NIC Intel Corporation Device Fortville [8086:1583]
- driver: i40e
- version: 2.4.3
- firmware-version: 6.01 0x80003205 1.1691.0
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 2 cases, 2 passed, 0 failed
---
app/test-pmd/cmdline.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
5885289..a0ed3a0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -16665,7 +16665,7 @@ struct cmd_config_per_port_rx_offload_result {
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security");
+ "crc_strip#scatter#timestamp#security#keep_crc");
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -16744,7 +16744,7 @@ struct cmd_config_per_port_rx_offload_result {
.help_str = "port config rx_offload vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
"macsec_strip|header_split|vlan_filter|vlan_extend|"
- "jumbo_frame|crc_strip|scatter|timestamp|security "
+ "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
"on|off",
.tokens = {
(void *)&cmd_config_per_port_rx_offload_result_port,
@@ -16794,7 +16794,7 @@ struct cmd_config_per_queue_rx_offload_result {
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security");
+ "crc_strip#scatter#timestamp#security#keep_crc");
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -16846,7 +16846,7 @@ struct cmd_config_per_queue_rx_offload_result {
"vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
"macsec_strip|header_split|vlan_filter|vlan_extend|"
- "jumbo_frame|crc_strip|scatter|timestamp|security "
+ "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
"on|off",
.tokens = {
(void *)&cmd_config_per_queue_rx_offload_result_port,
@@ -17063,7 +17063,7 @@ struct cmd_config_per_port_tx_offload_result {
"sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
"qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
"ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
- "mt_lockfree#multi_segs#fast_free#security");
+ "mt_lockfree#multi_segs#mbuf_fast_free#security");
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -17144,7 +17144,7 @@ struct cmd_config_per_port_tx_offload_result {
"sctp_cksum|tcp_tso|udp_tso|outer_ipv4_cksum|"
"qinq_insert|vxlan_tnl_tso|gre_tnl_tso|"
"ipip_tnl_tso|geneve_tnl_tso|macsec_insert|"
- "mt_lockfree|mul
Re: [dpdk-dev] [PATCH] examples/ip_pipeline: fix RSS
Tested-by: Peng, Yuan
- Tested Commit: 23888166d99682b1491a917277e4ff0ff01639b2
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1583]
- Default x86_64-native-linuxapp-gcc configuration
I have verified the ip_pipeline rss case with 18.08-rc2 applied your patch 43469
* ./build/ip_pipeline -c 0x1F -n 4 -- -s ./examples/rss.cli
* Start traffic on just one input port.
* output traffic was seen (in equal amounts) for each of the 4x output
ports
the bug is not represented.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Cristian Dumitrescu
Sent: Tuesday, July 31, 2018 10:49 PM
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH] examples/ip_pipeline: fix RSS
Fix for RSS issue triggered by latest changes in ethdev layer.
Signed-off-by: Cristian Dumitrescu
---
examples/ip_pipeline/link.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/examples/ip_pipeline/link.c b/examples/ip_pipeline/link.c index
2ccfea4..392a890 100644
--- a/examples/ip_pipeline/link.c
+++ b/examples/ip_pipeline/link.c
@@ -158,12 +158,9 @@ link_create(const char *name, struct link_params *params)
memcpy(&port_conf, &port_conf_default, sizeof(port_conf));
if (rss) {
port_conf.rxmode.mq_mode = ETH_MQ_RX_RSS;
- if (port_info.flow_type_rss_offloads & ETH_RSS_IPV4)
- port_conf.rx_adv_conf.rss_conf.rss_hf |=
- ETH_RSS_IPV4;
- if (port_info.flow_type_rss_offloads & ETH_RSS_IPV6)
- port_conf.rx_adv_conf.rss_conf.rss_hf |=
- ETH_RSS_IPV6;
+ port_conf.rx_adv_conf.rss_conf.rss_hf =
+ (ETH_RSS_IP | ETH_RSS_TCP | ETH_RSS_UDP) &
+ port_info.flow_type_rss_offloads;
}
cpu_id = (uint32_t) rte_eth_dev_socket_id(port_id);
--
2.7.4
Re: [dpdk-dev] [PATCH] app/testbbdev: fix inputs mbuf creation issue
Tested-by: Peng, Yuan
> NIC Fortville 4*10G
> ethtool -i ens785f1
> driver: i40e
> version: 2.4.10
> firmware-version: 6.01 0x80003205 1.1691.0 DPDK version: 18.11-rc0
> commit 76b9d9de5c7d747c381027156aac07735cb1bc0c
> FlexRAN-1.6.0
> Os: 4.4.0-62-generic
> ICC:parallel_studio_xe_2018_update1_professional_edition_for_cpp
> Set ``CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW=y``
> cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-4.4.0-62-generic root=UUID=673a4478-afa5-
> 463a-afa2-40681423994e ro hugepagesz=1G hugepages=16
> default_hugepagesz=1G isolcpus=1-43 intel_iommu=on nohz_full=1-43
> rcu_nocbs=1-43 iommu=pt
>
> ./usertools/dpdk-devbind.py -b vfio-pci 05:00.0 05:00.1
> ./app/test-bbdev/test-bbdev.py -e="--
> vdev=baseband_null,socket_id=0,max_nb_queues=8"
>
> the case can passed.
>
> Thanks.
> Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Kamil Chalupnik
Sent: Friday, August 17, 2018 3:19 PM
To: Mokhtar, Amr ; De Lara Guarch, Pablo
Cc: dev@dpdk.org; sta...@dpdk.org; Chalupnik, KamilX
Subject: [dpdk-dev] [PATCH] app/testbbdev: fix inputs mbuf creation issue
Omitting inputs and outputs mbuf creation for BaseBand Null Device as inputs
and outputs data do not exist for Null Device
Fixes: b2a4654f082b ("mempool: check for zero size creation")
Cc: pablo.de.lara.gua...@intel.com
Signed-off-by: Kamil Chalupnik
---
app/test-bbdev/test_bbdev_perf.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/app/test-bbdev/test_bbdev_perf.c b/app/test-bbdev/test_bbdev_perf.c
index 6861edc..fbe6cc9 100644
--- a/app/test-bbdev/test_bbdev_perf.c
+++ b/app/test-bbdev/test_bbdev_perf.c
@@ -267,12 +267,13 @@ typedef int (test_case_function)(struct active_device *ad,
static int
create_mempools(struct active_device *ad, int socket_id,
- enum rte_bbdev_op_type op_type, uint16_t num_ops)
+ enum rte_bbdev_op_type org_op_type, uint16_t num_ops)
{
struct rte_mempool *mp;
unsigned int ops_pool_size, mbuf_pool_size = 0;
char pool_name[RTE_MEMPOOL_NAMESIZE];
const char *op_type_str;
+ enum rte_bbdev_op_type op_type = org_op_type;
struct op_data_entries *in = &test_vector.entries[DATA_INPUT];
struct op_data_entries *hard_out =
@@ -289,6 +290,9 @@ typedef int (test_case_function)(struct active_device *ad,
OPS_CACHE_SIZE + 1)),
OPS_POOL_SIZE_MIN));
+ if (org_op_type == RTE_BBDEV_OP_NONE)
+ op_type = RTE_BBDEV_OP_TURBO_ENC;
+
op_type_str = rte_bbdev_op_type_str(op_type);
TEST_ASSERT_NOT_NULL(op_type_str, "Invalid op type: %u", op_type);
@@ -303,6 +307,10 @@ typedef int (test_case_function)(struct active_device *ad,
socket_id);
ad->ops_mempool = mp;
+ /* Do not create inputs and outputs mbufs for BaseBand Null Device */
+ if (org_op_type == RTE_BBDEV_OP_NONE)
+ return TEST_SUCCESS;
+
/* Inputs */
mbuf_pool_size = optimal_mempool_size(ops_pool_size * in->nb_segments);
mp = create_mbuf_pool(in, ad->dev_id, socket_id, mbuf_pool_size, "in");
@@ -1058,14 +1066,14 @@ typedef int (test_case_function)(struct active_device
*ad,
rte_bbdev_info_get(ad->dev_id, &info);
socket_id = GET_SOCKET(info.socket_id);
- if (op_type == RTE_BBDEV_OP_NONE)
- op_type = RTE_BBDEV_OP_TURBO_ENC;
f_ret = create_mempools(ad, socket_id, op_type,
get_num_ops());
if (f_ret != TEST_SUCCESS) {
printf("Couldn't create mempools");
goto fail;
}
+ if (op_type == RTE_BBDEV_OP_NONE)
+ op_type = RTE_BBDEV_OP_TURBO_ENC;
f_ret = init_test_op_params(op_params, test_vector.op_type,
test_vector.expected_status,
--
1.8.3.1
Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API
Hi，Adrien Mazarguil
There is a bug present with 18.05-rci when I test the feature "Move RSS to
rte_flow" in i40e NIC
The test steps are as below:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i --nb-cores=8
--rxq=8 --txq=8 --port-topology=chained
testpmd> set fwd rxonly
Set rxonly packet forwarding mode
testpmd> set verbose 1
Change verbose level from 0 to 1
testpmd> start
testpmd> flow create 0 ingress pattern end actions rss queues 0 4 7 end / end
Caught error type 16 (specific action): cause: 0x7fff84e33658, RSS hash key too
large
The rss rule can be set successfully when I test it yesterday with older dpdk
version without this patch.
The NIC information is:
driver: i40e
version: 2.4.3
firmware-version: 6.01 0x80003205 1.1691.0
There is another problem with ixgbe nic:
./usertools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i --nb-cores=8
--rxq=8 --txq=8 --disable-rss --port-topology=chained
testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 end / end
Caught error type 2 (flow rule (handle)): Failed to create flow.
The rule setting command can be executed successfully with older dpdk version.
Could you help to check if there is a relationship between the bugs and this
patch?
Thank you.
Yuan.
-Original Message-
From: Zhao1, Wei
Sent: Saturday, April 28, 2018 11:46 AM
To: Adrien Mazarguil ; dev@dpdk.org
Cc: Peng, Yuan ; Xu, Qian Q ; Liu, Yu
Y ; Lu, Wenzhuo ; Wu, Jingjing
Subject: RE: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in
flow API
Hi，Adrien Mazarguil
We have just use new RC.1 code on the feature of flow RSS API, but we
find some abnormal phenomenon.
After that I check code again, I find that it is introduced in this patch:
SHA-1: ac8d22de2394e03ba4a77d8fd24381147aafb1d3
* ethdev: flatten RSS configuration in flow API
Signed-off-by: Adrien Mazarguil
This abnormal phenomenon include i40e and ixgbe 2 NIC, it do not has these 2
bug before merge this patch.
It is first find out by yuan.p...@intel.com, she can tell you how to reappear
these abnormal phenomenon on RSS flow API.
Thank you.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Wednesday, April 25, 2018 11:28 PM
> To: Thomas Monjalon ; Yigit, Ferruh
> ; dev@dpdk.org
> Cc: Xueming Li ; Lu, Wenzhuo
> ; Wu, Jingjing ; Xing, Beilei
> ; Zhang, Qi Z ; Ananyev,
> Konstantin ; Nelio Laranjeiro
> ; Yongseok Koh ;
> Andrew Rybchenko ; Pascal Mazon
> ; Nicolau, Radu ; Akhil
> Goyal
> Subject: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in
> flow API
>
> Since its inception, the rte_flow RSS action has been relying in part on
> external struct rte_eth_rss_conf for compatibility with the legacy RSS API.
> This structure lacks parameters such as the hash algorithm to use, and more
> recently, a method to tell which layer RSS should be performed on [1].
>
> Given struct rte_eth_rss_conf will never be flexible enough to represent a
> complete RSS configuration (e.g. RETA table), this patch supersedes it by
> extending the rte_flow RSS action directly.
>
> A subsequent patch will add a field to use a non-default RSS hash
> algorithm. To that end, a field named "types" replaces the field formerly
> known as "rss_hf" and standing for "RSS hash functions" as it was
> confusing. Actual RSS hash function types are defined by enum
> rte_eth_hash_function.
>
> This patch updates all PMDs and example applications accordingly.
>
> It breaks ABI compatibility for the following public functions:
>
> - rte_flow_copy()
> - rte_flow_create()
> - rte_flow_query()
> - rte_flow_validate()
>
> [1] commit 676b605182a5 ("doc: announce ethdev API change for RSS
> configuration")
>
> Signed-off-by: Adrien Mazarguil
> Acked-by: Andrew Rybchenko
> Cc: Xueming Li
> Cc: Ferruh Yigit
> Cc: Thomas Monjalon
> Cc: Wenzhuo Lu
> Cc: Jingjing Wu
> Cc: Beilei Xing
> Cc: Qi Zhang
> Cc: Konstantin Ananyev
> Cc: Nelio Laranjeiro
> Cc: Yongseok Koh
> Cc: Andrew Rybchenko
> Cc: Pascal Mazon
> Cc: Radu Nicolau
> Cc: Akhil Goyal
>
> ---
>
> v6 changes:
>
> - Fixed QUEUE action support in mlx5 according to Nelio's comment [1].
> This action relies on RSS to work and even though it targets a single Rx
> queue, a non-NULL hash key is required.
> - Updated API and ABI changes sections in release notes.
>
> [1] http://dpdk.org/ml/archives/dev/2018-April/098635.html
>
> v3 changes:
>
> Documentation update regarding the meaning of a 0 value for RSS types in
> flow rules.
>
Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API
Hi，Adrien Mazarguil There is a bug of queue region with 18.05-rc1 The test steps are as below: ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 ./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -- -i --rxq=16 --txq=16 testpmd> port config all rss all Configuration of RSS hash at ethernet port 0 failed with error (22): Invalid argument. testpmd> set fwd rxonly testpmd> set verbose 1 testpmd> start testpmd> set port 0 queue-region region_id 0 queue_start_index 1 queue_num 1 testpmd> set port 0 queue-region region_id 0 flowtype 31 testpmd> set port 0 queue-region flush on testpmd> port 0/queue 0: received 1 packets src=00:13:3B:0C:21:95 - dst=00:00:00:00:01:00 - type=0x0800 - length=90 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP - sw ptype: L2_ETHER L3_IPV4 L4_UDP - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x0 ol_flags: PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD the packet should be distributed to queue 1 instead of queue0. And the command" port config all rss all" failed to execute. Could you help to check if this has relationship with your patches relevant to flow api? Thanks. Yuan. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Peng, Yuan Sent: Saturday, April 28, 2018 1:29 PM To: Zhao1, Wei ; Adrien Mazarguil ; dev@dpdk.org Cc: Xu, Qian Q ; Liu, Yu Y ; Lu, Wenzhuo ; Wu, Jingjing Subject: Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API Hi，Adrien Mazarguil There is a bug present with 18.05-rci when I test the feature "Move RSS to rte_flow" in i40e NIC The test steps are as below: ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1 ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i --nb-cores=8 --rxq=8 --txq=8 --port-topology=chained testpmd> set fwd rxonly Set rxonly packet forwarding mode testpmd> set verbose 1 Change verbose level from 0 to 1 testpmd> start testpmd> flow create 0 ingress pattern end actions rss queues 0 4 7 end / end Caught error type 16 (specific action): cause: 0x7fff84e33658, RSS hash key too large The rss rule can be set successfully when I test it yesterday with older dpdk version without this patch. The NIC information is: driver: i40e version: 2.4.3 firmware-version: 6.01 0x80003205 1.1691.0 There is another problem with ixgbe nic: ./usertools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1 ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i --nb-cores=8 --rxq=8 --txq=8 --disable-rss --port-topology=chained testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 end / end Caught error type 2 (flow rule (handle)): Failed to create flow. The rule setting command can be executed successfully with older dpdk version. Could you help to check if there is a relationship between the bugs and this patch? Thank you. Yuan. -Original Message- From: Zhao1, Wei Sent: Saturday, April 28, 2018 11:46 AM To: Adrien Mazarguil ; dev@dpdk.org Cc: Peng, Yuan ; Xu, Qian Q ; Liu, Yu Y ; Lu, Wenzhuo ; Wu, Jingjing Subject: RE: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API Hi，Adrien Mazarguil We have just use new RC.1 code on the feature of flow RSS API, but we find some abnormal phenomenon. After that I check code again, I find that it is introduced in this patch: SHA-1: ac8d22de2394e03ba4a77d8fd24381147aafb1d3 * ethdev: flatten RSS configuration in flow API Signed-off-by: Adrien Mazarguil This abnormal phenomenon include i40e and ixgbe 2 NIC, it do not has these 2 bug before merge this patch. It is first find out by yuan.p...@intel.com, she can tell you how to reappear these abnormal phenomenon on RSS flow API. Thank you. > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil > Sent: Wednesday, April 25, 2018 11:28 PM > To: Thomas Monjalon ; Yigit, Ferruh > ; dev@dpdk.org > Cc: Xueming Li ; Lu, Wenzhuo > ; Wu, Jingjing ; Xing, Beilei > ; Zhang, Qi Z ; Ananyev, > Konstantin ; Nelio Laranjeiro > ; Yongseok Koh ; > Andrew Rybchenko ; Pascal Mazon > ; Nicolau, Radu ; Akhil > Goyal > Subject: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in > flow API > > Since its inception, the rte_flow RSS action has been relying in part on > external struct rte_eth_rss_conf for compatibility with the legacy RSS API. > This structure lacks parameters such as the hash algorithm to use, and more > recently, a method to tell which layer RSS should be performed on [1]. > > Given struct rte_eth_rss_conf will never be flexible enough to represent a > complete RSS configuration (e.g. RETA table), this patch supersedes it by > extending the rte_flow RSS action directly. > > A subsequent patch will add a field to use a non-default RSS hash > algorithm. To that end, a field named "types" replaces
Re: [dpdk-dev] [PATCH v6 07/11] app/testpmd: fix RSS flow action configuration
Hi Adrien,
There is a core dump when I set i40e fdir flexbytes rule, I bisect the commit
version,
d0ad8648b1c57c0e311ab7a3192bc3b507de5bf6 is the first bad commit
commit d0ad8648b1c57c0e311ab7a3192bc3b507de5bf6
Author: Adrien Mazarguil
Date: Thu Apr 19 12:07:37 2018 +0200
app/testpmd: fix RSS flow action configuration
Except for a list of queues, RSS configuration (hash key and fields) cannot
be specified from the flow command line and testpmd does not provide safe
defaults either.
In order to validate their implementation with testpmd, PMDs had to
interpret its NULL RSS configuration parameters somehow, however this has
never been valid to begin with.
This patch makes testpmd always provide default values.
The list of RSS types to use is exclusively taken from the global "rss_hf"
variable, itself configured through the "port config all rss" command or
--rss-ip/--rss-udp command-line options.
Fixes: 05d34c6e9d2c ("app/testpmd: add queue actions to flow command")
Cc: sta...@dpdk.org
Signed-off-by: Adrien Mazarguil
Acked-by: Nelio Laranjeiro
Acked-by: Ferruh Yigit
:04 04 1e01ca01e840f43334f576a2fe8cf755433e9c90
1ff48b7ff1f01a399cd3403c5fc6e537d2f33021 M app
The test steps are as below:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1
./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -w :05:00.0
--file-prefix=pf - -i --pkt-filter-mode=perfect --disable-rss --rxq=16 --txq=16
testpmd> flow create 0 ingress pattern eth type is 0x0807 / raw relative is 1
pattern is abcdefghijklmnop / end actions queue index 1 / end
PMD: Global register is changed during enable FDIR flexible payload
Segmentation fault (core dumped)
Could you help to check it?
Thank you very much.
Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
Sent: Thursday, April 19, 2018 6:08 PM
To: dev@dpdk.org
Cc: sta...@dpdk.org; Lu, Wenzhuo ; Wu, Jingjing
; Xueming Li
Subject: [dpdk-dev] [PATCH v6 07/11] app/testpmd: fix RSS flow action
configuration
Except for a list of queues, RSS configuration (hash key and fields) cannot be
specified from the flow command line and testpmd does not provide safe defaults
either.
In order to validate their implementation with testpmd, PMDs had to interpret
its NULL RSS configuration parameters somehow, however this has never been
valid to begin with.
This patch makes testpmd always provide default values.
The list of RSS types to use is exclusively taken from the global "rss_hf"
variable, itself configured through the "port config all rss" command or
--rss-ip/--rss-udp command-line options.
Fixes: 05d34c6e9d2c ("app/testpmd: add queue actions to flow command")
Cc: sta...@dpdk.org
Signed-off-by: Adrien Mazarguil
Acked-by: Nelio Laranjeiro
Cc: Wenzhuo Lu
Cc: Jingjing Wu
Cc: Xueming Li
---
v4 changes:
Removed reliance on rte_eth_dev_rss_hash_conf_get(), which as reported by
Xueming, is not necessarily supported and triggers a misleading "Function not
implemented" warning. Updated commit log to reflect this.
---
app/test-pmd/cmdline.c | 2 +
app/test-pmd/cmdline_flow.c | 101
app/test-pmd/config.c | 140 +++
3 files changed, 190 insertions(+), 53 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
512e3b55e..9704d0454 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2033,6 +2033,8 @@ cmd_config_rss_parsed(void *parsed_result,
return;
}
rss_conf.rss_key = NULL;
+ /* Update global configuration for RSS types. */
+ rss_hf = rss_conf.rss_hf;
for (i = 0; i < rte_eth_dev_count(); i++) {
diag = rte_eth_dev_rss_hash_update(i, &rss_conf);
if (diag < 0)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index
a0e06db36..d37c5f39f 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -184,13 +184,19 @@ enum index {
#define ITEM_RAW_SIZE \
(offsetof(struct rte_flow_item_raw, pattern) + ITEM_RAW_PATTERN_SIZE)
-/** Number of queue[] entries in struct rte_flow_action_rss. */ -#define
ACTION_RSS_NUM 32
-
-/** Storage size for struct rte_flow_action_rss including queues. */ -#define
ACTION_RSS_SIZE \
- (offsetof(struct rte_flow_action_rss, queue) + \
-sizeof(*((struct rte_flow_action_rss *)0)->queue) * ACTION_RSS_NUM)
+/** Maximum number of queue indices in struct rte_flow_action_rss. */
+#define ACTION_RSS_QUEUE_NUM 32
+
+/** Storage for struct rte_flow_action_rss including external data. */
+union action_rss_data {
+ struct rte_flow_action_rss conf;
+ struct {
+ uint8_t conf_data[offsetof(struct rte_flow_action_rss, queue)];
+ uint16_t queue[ACTION_RSS_QUEUE_NUM];
+ struct rte_eth_rss_conf rss_conf;
+
Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API
Hi Adrien, The third problem which use ixgbe NIC: I add " key_len 0 types ip udp end " to the command "flow create 0 ingress pattern end actions rss queues 5 6 7 end / end" It shows: testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 end / key_len 0 types ip udp end / end Bad arguments testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 / key_len 0 types ip udp end / end Bad arguments testpmd> key_len 0 types ip udp end Command not found Could you show me the correct command? Thanks. Yuan. -Original Message- From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] Sent: Friday, May 4, 2018 5:45 PM To: Zhao1, Wei Cc: Peng, Yuan ; dev@dpdk.org; Xu, Qian Q ; Liu, Yu Y ; Lu, Wenzhuo ; Wu, Jingjing Subject: Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API On Fri, May 04, 2018 at 09:31:05AM +, Zhao1, Wei wrote: > Hi, Adrien Mazarguil > > > -Original Message- > > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] > > Sent: Thursday, May 3, 2018 8:48 PM > > To: Peng, Yuan > > Cc: Zhao1, Wei ; dev@dpdk.org; Xu, Qian Q > > ; Liu, Yu Y ; Lu, Wenzhuo > > ; Wu, Jingjing > > Subject: Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS > > configuration in flow API > > > > Hi Peng Yuan, > > > > Apologies for the delay, I'll answer below to the entire thread. > > > > On Sat, Apr 28, 2018 at 07:45:31AM +, Peng, Yuan wrote: > > > Hi，Adrien Mazarguil > > > > > > There is a bug of queue region with 18.05-rc1 The test steps are > > > as > > > below: > > > ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 > > > ./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -- -i > > > --rxq=16 > > > --txq=16 > > > testpmd> port config all rss all > > > Configuration of RSS hash at ethernet port 0 failed with error > > > (22): Invalid > > argument. > > > > I assume this issue is related rte_eth_dev_configure() which was > > recently fixed [1], right? > > > > [1] "ethdev: fix applications failure on configure" > > http://dpdk.org/ml/archives/dev/2018-May/099858.html > > > > > > > There is a bug present with 18.05-rci when I test the feature > > > "Move RSS to rte_flow" in i40e NIC The test steps are as below: > > > ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1 > > > ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i > > > --nb-cores=8 --rxq=8 --txq=8 --port-topology=chained > > > testpmd> set fwd rxonly > > > Set rxonly packet forwarding mode > > > testpmd> set verbose 1 > > > Change verbose level from 0 to 1 > > > testpmd> start > > > testpmd> flow create 0 ingress pattern end actions rss queues 0 4 > > > testpmd> 7 end / end > > > Caught error type 16 (specific action): cause: 0x7fff84e33658, RSS > > > hash key too large > > > > > > The rss rule can be set successfully when I test it yesterday with > > > older dpdk > > version without this patch. > > > > Regarding this issue, the testpmd flow command now requests hash key > > length from the PMD by default [2] if left unspecified by user. This > > value is taken from the "hash_key_size" field returned by > > rte_eth_dev_infos_get(). > > > > While most PMDs return 40 here, i40e returns: > > > > (I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t) > > /* that is, (12 + 1) * 4 => 52 */ > > > > Is this correct and really supported by i40e? Otherwise I'd suggest > > to fix the PMD as it may also confuse applications other than testpmd. > > > > Note that you should be able to revert to the old behavior with the > > PMD- specific default key by specifying a "key_len 0" parameter to the RSS > > action. > > > > [2] http://dpdk.org/browse/dpdk/tree/app/test- > > pmd/cmdline_flow.c?id=v18.05-rc2#n2780 > > > This is the root cause for this issue, although i40 return : > > dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX + 1) * > sizeof(uint32_t); > > that is 52 byte, but " RTE_DIM(rss_config->key)" ， which is > > uint8_t key[(I40E_VFQF_HKEY_MAX_INDEX > I40E_PFQF_HKEY_MAX_INDEX ? >I40E_VFQF_HKEY_MAX_INDEX : I40E_PFQF_HKEY_MAX_INDEX) + 1 * > sizeof(uint32_t)]; /* Hash key. */ is not 52!!! > > I think the code should be : > > uint8_t
Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API
Hi Adrien, I configure the command as: testpmd> flow create 0 ingress pattern end actions rss types udp end queues 5 end / end Flow rule #0 created The rule can be set successfully. It seems like you have added several parameter to the feature, and modified the command format. testpmd> flow create 0 ingress pattern end actions rss func [TOKEN]: RSS hash function to apply level [TOKEN]: encapsulation level for "types" types [TOKEN]: specific RSS hash types key [TOKEN]: RSS hash key key_len [TOKEN]: RSS hash key length in bytes queues [TOKEN]: queue indices to use / [TOKEN]: specify next action Could you send me and Zhao Wei a user guideline? Thank you. Yuan. -Original Message----- From: Peng, Yuan Sent: Monday, May 7, 2018 3:42 PM To: 'Adrien Mazarguil' ; Zhao1, Wei Cc: dev@dpdk.org; Xu, Qian Q ; Liu, Yu Y ; Lu, Wenzhuo ; Wu, Jingjing Subject: RE: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API Hi Adrien, The third problem which use ixgbe NIC: I add " key_len 0 types ip udp end " to the command "flow create 0 ingress pattern end actions rss queues 5 6 7 end / end" It shows: testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 end testpmd> / key_len 0 types ip udp end / end Bad arguments testpmd> flow create 0 ingress pattern end actions rss queues 5 6 7 / testpmd> key_len 0 types ip udp end / end Bad arguments testpmd> key_len 0 types ip udp end Command not found Could you show me the correct command? Thanks. Yuan. -Original Message- From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] Sent: Friday, May 4, 2018 5:45 PM To: Zhao1, Wei Cc: Peng, Yuan ; dev@dpdk.org; Xu, Qian Q ; Liu, Yu Y ; Lu, Wenzhuo ; Wu, Jingjing Subject: Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS configuration in flow API On Fri, May 04, 2018 at 09:31:05AM +, Zhao1, Wei wrote: > Hi, Adrien Mazarguil > > > -Original Message- > > From: Adrien Mazarguil [mailto:adrien.mazarg...@6wind.com] > > Sent: Thursday, May 3, 2018 8:48 PM > > To: Peng, Yuan > > Cc: Zhao1, Wei ; dev@dpdk.org; Xu, Qian Q > > ; Liu, Yu Y ; Lu, Wenzhuo > > ; Wu, Jingjing > > Subject: Re: [dpdk-dev] [PATCH v6 07/16] ethdev: flatten RSS > > configuration in flow API > > > > Hi Peng Yuan, > > > > Apologies for the delay, I'll answer below to the entire thread. > > > > On Sat, Apr 28, 2018 at 07:45:31AM +, Peng, Yuan wrote: > > > Hi，Adrien Mazarguil > > > > > > There is a bug of queue region with 18.05-rc1 The test steps are > > > as > > > below: > > > ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 > > > ./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -- -i > > > --rxq=16 > > > --txq=16 > > > testpmd> port config all rss all > > > Configuration of RSS hash at ethernet port 0 failed with error > > > (22): Invalid > > argument. > > > > I assume this issue is related rte_eth_dev_configure() which was > > recently fixed [1], right? > > > > [1] "ethdev: fix applications failure on configure" > > http://dpdk.org/ml/archives/dev/2018-May/099858.html > > > > > > > There is a bug present with 18.05-rci when I test the feature > > > "Move RSS to rte_flow" in i40e NIC The test steps are as below: > > > ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1 > > > ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1fffe -n 4 -- -i > > > --nb-cores=8 --rxq=8 --txq=8 --port-topology=chained > > > testpmd> set fwd rxonly > > > Set rxonly packet forwarding mode > > > testpmd> set verbose 1 > > > Change verbose level from 0 to 1 > > > testpmd> start > > > testpmd> flow create 0 ingress pattern end actions rss queues 0 4 > > > testpmd> 7 end / end > > > Caught error type 16 (specific action): cause: 0x7fff84e33658, RSS > > > hash key too large > > > > > > The rss rule can be set successfully when I test it yesterday with > > > older dpdk > > version without this patch. > > > > Regarding this issue, the testpmd flow command now requests hash key > > length from the PMD by default [2] if left unspecified by user. This > > value is taken from the "hash_key_size" field returned by > > rte_eth_dev_infos_get(). > > > > While most PMDs return 40 here, i40e returns: > > > > (I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t) > > /* that is, (12 + 1) * 4 => 52 */ > > > > Is this correct and really supported by i40e? Otherwise I'd suggest &
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
Hi Wei,
There is a build error applied your patches to the latest DPDK version.
/root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_rxq':
/root/dpdk/app/test-pmd/testpmd.c:579:3: error: 'pid' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
printf("Fail: input rxq (%u) can't be greater "
^
/root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_txq':
/root/dpdk/app/test-pmd/testpmd.c:625:3: error: 'pid' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
printf("Fail: input txq (%u) can't be greater "
^
My gcc verison is gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
Could you help to check it?
Thanks.
Yuan.
-Original Message-
From: Dai, Wei
Sent: Thursday, January 11, 2018 12:58 PM
To: Ananyev, Konstantin ; Yang, Qiming
; Peng, Yuan ; Lu, Wenzhuo
; Wu, Jingjing
Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
Subject: [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
If an invlaid number of RX or TX queues is configured from testpmd command like
"port config all rxq number" or "port config all txq number".
or from --rxq and --txq in the command to start testpmd. The global variable
nb_rxq or nb_txq is updated by the invalid input.
This can cause testpmd crash. For example, if the maximum number of RX or TX
queues is 4, testpmd will crash after running commands "port config all rxq 5",
"port config all txq 5" and "start" in sequence.
With these 2 patches, if an invalid input is detected, it is refused and
testpmd keeps last correct values of nb_rxq and nb_txq.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Aced-by: Konstantin Ananyev
---
v4: update git log message and rename 2 new added functions
v3: follow the guide from Konstantin to use functions to check
input rxq and txq instead of usage of new added global variables.
v2: fix a bug in v1
Wei Dai (2):
app/testpmd: fix invalid rxq number setting
app/testpmd: fix invalid txq number setting
app/test-pmd/cmdline.c| 4 +++
app/test-pmd/parameters.c | 13 +++
app/test-pmd/testpmd.c| 92 +++
app/test-pmd/testpmd.h| 5 +++
4 files changed, 108 insertions(+), 6 deletions(-)
--
2.7.5
Re: [dpdk-dev] [PATCH v5 1/2] app/testpmd: fix invalid rxq number setting
Tested-by: Peng Yuan
- Tested Branch: master
- Tested commit 6c7001480ac6356ff0a4995f3ed495ed9c866061
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1572]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 05:00:0 echo 1
>/sys/bus/pci/devices/:05:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 05:02.0
pf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w
05:00.0,queue-num-per-vf=4 --file-prefix=test1 --socket-mem 1024,1024 - -I
vf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w 05:02.0
--file-prefix=test2 --socket-mem 1024,1024 - -i --rxq=4 --txq=4
EAL: Detected 88 lcore(s)
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :05:02.0 on NUMA socket 0
EAL: probe driver: 8086:154c net_i40e_vf
EAL: using IOMMU type 1 (Type 1)
Interactive-mode selected
USER1: create a new mbuf pool : n=171456, size=2176,
socket=0
USER1: create a new mbuf pool : n=171456, size=2176,
socket=1 Configuring Port 0 (socket 0) Port 0: 7E:AC:58:44:3C:94 Checking
link statuses...
Done
testpmd> port stop all
Stopping ports...
Checking link statuses...
Done
testpmd> port config all txq 5
Fail: input txq (5) can't be greater than max_tx_queues (4) of port 0
testpmd> port config all rxq 5
Fail: input rxq (5) can't be greater than max_rx_queues (4) of port 0
testpmd> port start all Port 0: 5A:19:E4:5C:A3:C7 Checking link statuses...
Done
testpmd> show port info all
Current number of RX queues: 4
Max possible RX queues: 4
Current number of TX queues: 4
Max possible TX queues: 4
there is no core dump, and the actual queue number doesn't change.
The case passed.
-Original Message-
From: Dai, Wei
Sent: Friday, January 12, 2018 4:10 PM
To: Peng, Yuan ; Ananyev, Konstantin
; Lu, Wenzhuo ; Xing,
Beilei
Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
Subject: [PATCH v5 1/2] app/testpmd: fix invalid rxq number setting
If an invalid number of RX queues is configured from testpmd run-time command
like "port config all rxq number" or from --rxq in the command to start
testpmd, the global variable nb_rxq is updated by this invalid value without
this patch. It may cause testpmd crash. This patch refuses invalid rxq setting
and keeps its last correct value.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Acked-by: Konstantin Ananyev
---
app/test-pmd/cmdline.c| 2 ++
app/test-pmd/parameters.c | 7 ---
app/test-pmd/testpmd.c| 46 ++
app/test-pmd/testpmd.h| 3 +++
4 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
5b2e2ef..f0623b1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1518,6 +1518,8 @@ cmd_config_rx_tx_parsed(void *parsed_result,
printf("Warning: Either rx or tx queues should be non
zero\n");
return;
}
+ if (check_nb_rxq(res->value) != 0)
+ return;
nb_rxq = res->value;
}
else if (!strcmp(res->name, "txq")) {
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
304b98d..c46e734 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -536,6 +536,7 @@ launch_args_parse(int argc, char** argv)
int n, opt;
char **argvopt;
int opt_idx;
+ portid_t pid;
enum { TX, RX };
static struct option lgopts[] = {
@@ -922,12 +923,12 @@ launch_args_parse(int argc, char** argv)
rss_hf = ETH_RSS_UDP;
if (!strcmp(lgopts[opt_idx].name, "rxq")) {
n = atoi(optarg);
- if (n >= 0 && n <= (int) MAX_QUEUE_ID)
+ if (n >= 0 && check_nb_rxq((queueid_t)n) == 0)
nb_rxq = (queueid_t) n;
else
rte_exit(EXIT_FAILURE, "rxq %d invalid
- must be"
- " >= 0 && <= %d\n", n,
- (int) MAX_QUEUE_ID);
+ " >= 0 && <= %u\n", n,
+ get_allowed_max_nb_rxq(&pid));
}
if (!strcmp(lgopts[opt_idx].name, "txq")) {
Re: [dpdk-dev] [PATCH v5 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
Tested-by: Peng Yuan
- Tested Branch: master
- Tested commit 6c7001480ac6356ff0a4995f3ed495ed9c866061
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1572]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 05:00:0
echo 1 >/sys/bus/pci/devices/:05:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 05:02.0
pf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w
05:00.0,queue-num-per-vf=4 --file-prefix=test1 --socket-mem 1024,1024 - -I
vf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w 05:02.0
--file-prefix=test2 --socket-mem 1024,1024 - -i --rxq=4 --txq=4
EAL: Detected 88 lcore(s)
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :05:02.0 on NUMA socket 0
EAL: probe driver: 8086:154c net_i40e_vf
EAL: using IOMMU type 1 (Type 1)
Interactive-mode selected
USER1: create a new mbuf pool : n=171456, size=2176,
socket=0
USER1: create a new mbuf pool : n=171456, size=2176,
socket=1
Configuring Port 0 (socket 0)
Port 0: 7E:AC:58:44:3C:94
Checking link statuses...
Done
testpmd> port stop all
Stopping ports...
Checking link statuses...
Done
testpmd> port config all txq 5
Fail: input txq (5) can't be greater than max_tx_queues (4) of port 0
testpmd> port config all rxq 5
Fail: input rxq (5) can't be greater than max_rx_queues (4) of port 0
testpmd> port start all
Port 0: 5A:19:E4:5C:A3:C7
Checking link statuses...
Done
testpmd> show port info all
Current number of RX queues: 4
Max possible RX queues: 4
Current number of TX queues: 4
Max possible TX queues: 4
there is no core dump, and the actual queue number doesn't change.
The case passed.
-Original Message-
From: Dai, Wei
Sent: Friday, January 12, 2018 4:10 PM
To: Peng, Yuan ; Ananyev, Konstantin
; Lu, Wenzhuo ; Xing,
Beilei
Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
Subject: [PATCH v5 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
If an invlaid number of RX or TX queues is configured from testpmd command like
"port config all rxq number" or "port config all txq number".
or from --rxq and --txq in the command to start testpmd. The global variable
nb_rxq or nb_txq is updated by the invalid input.
This can cause testpmd crash. For example, if the maximum number of RX or TX
queues is 4, testpmd will crash after running commands "port config all rxq 5",
"port config all txq 5" and "start" in sequence.
With these 2 patches, if an invalid input is detected, it is refused and
testpmd keeps last correct values of nb_rxq and nb_txq.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Aced-by: Konstantin Ananyev
---
v5: fix building failure with -Werror=maybe-uninitialized by gcc 5.3.1
fix typo error
v4: update git log message and rename 2 new added functions
v3: follow the guide from Konstantin to use functions to check
input rxq and txq instead of usage of new added global variables.
v2: fix a bug in v1
Wei Dai (2):
app/testpmd: fix invalid rxq number setting
app/testpmd: fix invalid txq number setting
app/test-pmd/cmdline.c| 4 +++
app/test-pmd/parameters.c | 13 +++
app/test-pmd/testpmd.c| 92 +++
app/test-pmd/testpmd.h| 5 +++
4 files changed, 108 insertions(+), 6 deletions(-)
--
2.7.5
Re: [dpdk-dev] [PATCH v5 2/2] app/testpmd: fix invalid txq number setting
Tested-by: Peng Yuan
- Tested Branch: master
- Tested commit 6c7001480ac6356ff0a4995f3ed495ed9c866061
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1572]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- Case:
./usertools/dpdk-devbind.py -b igb_uio 05:00:0 echo 1
>/sys/bus/pci/devices/:05:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 05:02.0
pf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w
05:00.0,queue-num-per-vf=4 --file-prefix=test1 --socket-mem 1024,1024 - -I
vf:
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -w 05:02.0
--file-prefix=test2 --socket-mem 1024,1024 - -i --rxq=4 --txq=4
EAL: Detected 88 lcore(s)
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :05:02.0 on NUMA socket 0
EAL: probe driver: 8086:154c net_i40e_vf
EAL: using IOMMU type 1 (Type 1)
Interactive-mode selected
USER1: create a new mbuf pool : n=171456, size=2176,
socket=0
USER1: create a new mbuf pool : n=171456, size=2176,
socket=1 Configuring Port 0 (socket 0) Port 0: 7E:AC:58:44:3C:94 Checking
link statuses...
Done
testpmd> port stop all
Stopping ports...
Checking link statuses...
Done
testpmd> port config all txq 5
Fail: input txq (5) can't be greater than max_tx_queues (4) of port 0
testpmd> port config all rxq 5
Fail: input rxq (5) can't be greater than max_rx_queues (4) of port 0
testpmd> port start all Port 0: 5A:19:E4:5C:A3:C7 Checking link statuses...
Done
testpmd> show port info all
Current number of RX queues: 4
Max possible RX queues: 4
Current number of TX queues: 4
Max possible TX queues: 4
there is no core dump, and the actual queue number doesn't change.
The case passed.
-Original Message-
From: Dai, Wei
Sent: Friday, January 12, 2018 4:10 PM
To: Peng, Yuan ; Ananyev, Konstantin
; Lu, Wenzhuo ; Xing,
Beilei
Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
Subject: [PATCH v5 2/2] app/testpmd: fix invalid txq number setting
If an invalid number of TX queues is configured from testpmd run-time command
like "port config all txq number" or from --txq in the command to start
testpmd, the global variable nb_txq is updated by this invalid value without
this patch. It may cause testpmd crash. This patch refuses invalid txq setting
and keeps its last correct value.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org
Signed-off-by: Wei Dai
Acked-by: Konstantin Ananyev
---
app/test-pmd/cmdline.c| 2 ++
app/test-pmd/parameters.c | 6 +++---
app/test-pmd/testpmd.c| 46 ++
app/test-pmd/testpmd.h| 2 ++
4 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
f0623b1..6619cb8 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1527,6 +1527,8 @@ cmd_config_rx_tx_parsed(void *parsed_result,
printf("Warning: Either rx or tx queues should be non
zero\n");
return;
}
+ if (check_nb_txq(res->value) != 0)
+ return;
nb_txq = res->value;
}
else if (!strcmp(res->name, "rxd")) {
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
c46e734..ca2af65 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -932,12 +932,12 @@ launch_args_parse(int argc, char** argv)
}
if (!strcmp(lgopts[opt_idx].name, "txq")) {
n = atoi(optarg);
- if (n >= 0 && n <= (int) MAX_QUEUE_ID)
+ if (n >= 0 && check_nb_txq((queueid_t)n) == 0)
nb_txq = (queueid_t) n;
else
rte_exit(EXIT_FAILURE, "txq %d invalid
- must be"
- " >= 0 && <= %d\n", n,
- (int) MAX_QUEUE_ID);
+ " >= 0 && <= %u\n", n,
+ get_allowed_max_nb_txq(&pid));
}
if (!nb_rxq && !nb_txq) {
rte_exit(EXIT_FAILURE, "Either rx or tx queues
should "
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
4e8667d..493e028 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -586,6 +586,52 @@ check_nb_rxq(queueid_t rxq)
return
Re: [dpdk-dev] [PATCH v7 0/2] net/i40e: API to configure queue regions for RSS
Tested-by: Peng Yuan
- Tested Branch: dpdk-next-net/master
- Tested Commit: 9d660ac14ed6aa8688141b33fd6cd69fe3f0e5dd
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1572]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 3 cases, 3 passed, 0 failed
- Prerequisites command / instruction:
1. Hardware:
Fortville
2. software:
dpdk: http://dpdk.org/git/dpdk
scapy: http://www.secdev.org/projects/scapy/
3. bind the port to dpdk driver::
./usertools/dpdk-devbind.py -b igb_uio 05:00.0
the mac address of 05:00.0 is 00:00:00:00:01:00
4. start the testpmd::
./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -- -i --rxq=16
--txq=16
testpmd> port config all rss all
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
- Cases:
Test case 1: different pctype packet can enter the expected queue region
1. Set queue region on a port::
testpmd> set port 0 queue-region region_id 0 queue_start_index 1 queue_num 1
testpmd> set port 0 queue-region region_id 1 queue_start_index 3 queue_num 2
testpmd> set port 0 queue-region region_id 2 queue_start_index 6 queue_num 2
testpmd> set port 0 queue-region region_id 3 queue_start_index 8 queue_num 2
testpmd> set port 0 queue-region region_id 4 queue_start_index 11 queue_num
4
testpmd> set port 0 queue-region region_id 5 queue_start_index 15 queue_num
1
2. Set the mapping of flowtype to region index on a port::
testpmd> set port 0 queue-region region_id 0 flowtype 31
testpmd> set port 0 queue-region region_id 1 flowtype 32
testpmd> set port 0 queue-region region_id 2 flowtype 33
testpmd> set port 0 queue-region region_id 3 flowtype 34
testpmd> set port 0 queue-region region_id 4 flowtype 35
testpmd> set port 0 queue-region region_id 5 flowtype 45
testpmd> set port 0 queue-region region_id 2 flowtype 41
testpmd> flush port 0 queue-region on
3. send packet::
pkt1 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/UDP(sport=23,dport=24)/Raw('x'*20)
pkt2 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/TCP(sport=33,dport=34,flags="S")/Raw('x'*20)
pkt3 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/TCP(sport=33,dport=34,flags="PA")/Raw('x' * 20)
pkt4 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/SCTP(sport=44,dport=45,tag=1)/SCTPChunkData(data="X" * 20)
pkt5 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1", dst="192.168.0.2")/Raw('x'*20)
pkt6 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IPv6(src="2001::1", dst="2001::2")/Raw('x' * 20)
pkt7 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IPv6(src="2001::1",
dst="2001::2")/UDP(sport=24,dport=25)/Raw('x'*20)
pkt8 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/Dot1Q(prio=1)/IP(src="192.168.0.1",
dst="192.168.0.2")/Raw('x'*20)
verify the pkt1 to queue 1, pkt2 to queue 3 or queue 4,
pkt3 to queue 6 or queue 7, pkt4 to queue 8 or queue 9,
pkt5 to queue 11 or 12 or 13 or 14,
pkt6 to queue 15, pkt7 to queue 6 or queue 7,
pkt8 enter the same queue with pkt5.
4. verified the rules can be listed and flushed::
testpmd> get port 0 queue-region
testpmd> flush port 0 queue-region off
Notes: fortville can't parse the TCP SYN type packet, fortpark can parse it.
So if fortville, pkt2 to queue 6 or queue 7.
Test case 2: different user priority packet can enter the expected queue region
===
1. Set queue region on a port::
testpmd> set port 0 queue-region region_id 0 queue_start_index 0 queue_num 1
testpmd> set port 0 queue-region region_id 7 queue_start_index 1 queue_num 8
testpmd> set port 0 queue-region region_id 2 queue_start_index 10 queue_num
4
2. Set the mapping of User Priority to Traffic Classes on a port::
testpmd> set port 0 queue-region UP 3 region_id 0
testpmd> set port 0 queue-region UP 1 region_id 7
testpmd> set port 0 queue-region UP 2 region_id 2
testpmd> set port 0
Re: [dpdk-dev] [PATCH v8 0/2] net/i40e: API to configure queue regions for RSS
Tested-by: Peng Yuan
- Tested Branch: dpdk-master
- Tested Commit: 7a8889324654c9e39f9e18097ccc74d6ff2588cf
- OS: 4.5.5-300.fc24.x86_64
- GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1572]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 3 cases, 3 passed, 0 failed
- Prerequisites command / instruction:
1. Hardware:
Fortville
2. software:
dpdk: http://dpdk.org/git/dpdk
scapy: http://www.secdev.org/projects/scapy/
3. bind the port to dpdk driver::
./usertools/dpdk-devbind.py -b igb_uio 05:00.0
the mac address of 05:00.0 is 00:00:00:00:01:00
4. start the testpmd::
./x86_64-native-linuxapp-gcc/app/testpmd -c 1 -n 4 -- -i --rxq=16
--txq=16
testpmd> port config all rss all
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
- Cases:
Test case 1: different pctype packet can enter the expected queue region
1. Set queue region on a port::
testpmd> set port 0 queue-region region_id 0 queue_start_index 1 queue_num 1
testpmd> set port 0 queue-region region_id 1 queue_start_index 3 queue_num 2
testpmd> set port 0 queue-region region_id 2 queue_start_index 6 queue_num 2
testpmd> set port 0 queue-region region_id 3 queue_start_index 8 queue_num 2
testpmd> set port 0 queue-region region_id 4 queue_start_index 11 queue_num
4
testpmd> set port 0 queue-region region_id 5 queue_start_index 15 queue_num
1
2. Set the mapping of flowtype to region index on a port::
testpmd> set port 0 queue-region region_id 0 flowtype 31
testpmd> set port 0 queue-region region_id 1 flowtype 32
testpmd> set port 0 queue-region region_id 2 flowtype 33
testpmd> set port 0 queue-region region_id 3 flowtype 34
testpmd> set port 0 queue-region region_id 4 flowtype 35
testpmd> set port 0 queue-region region_id 5 flowtype 45
testpmd> set port 0 queue-region region_id 2 flowtype 41
testpmd> set port 0 queue-region flush on
3. send packet::
pkt1 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/UDP(sport=23,dport=24)/Raw('x'*20)
pkt2 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/TCP(sport=33,dport=34,flags="S")/Raw('x'*20)
pkt3 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/TCP(sport=33,dport=34,flags="PA")/Raw('x' * 20)
pkt4 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1",
dst="192.168.0.2")/SCTP(sport=44,dport=45,tag=1)/SCTPChunkData(data="X" * 20)
pkt5 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IP(src="192.168.0.1", dst="192.168.0.2")/Raw('x'*20)
pkt6 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IPv6(src="2001::1", dst="2001::2")/Raw('x' * 20)
pkt7 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/IPv6(src="2001::1",
dst="2001::2")/UDP(sport=24,dport=25)/Raw('x'*20)
pkt8 = Ether(dst="00:00:00:00:01:00",
src="00:02:00:00:00:01")/Dot1Q(prio=1)/IP(src="192.168.0.1",
dst="192.168.0.2")/Raw('x'*20)
verify the pkt1 to queue 1, pkt2 to queue 3 or queue 4,
pkt3 to queue 6 or queue 7, pkt4 to queue 8 or queue 9,
pkt5 to queue 11 or 12 or 13 or 14,
pkt6 to queue 15, pkt7 to queue 6 or queue 7,
pkt8 enter the same queue with pkt5.
4. verified the rules can be listed and flushed::
testpmd> show port 0 queue-region
testpmd> set port 0 queue-region flush off
Notes: fortville can't parse the TCP SYN type packet, fortpark can parse it.
So if fortville, pkt2 to queue 6 or queue 7.
Test case 2: different user priority packet can enter the expected queue region
===
1. Set queue region on a port::
testpmd> set port 0 queue-region region_id 0 queue_start_index 0 queue_num 1
testpmd> set port 0 queue-region region_id 7 queue_start_index 1 queue_num 8
testpmd> set port 0 queue-region region_id 2 queue_start_index 10 queue_num
4
2. Set the mapping of User Priority to Traffic Classes on a port::
testpmd> set port 0 queue-region UP 3 region_id 0
testpmd> set port 0 queue-region UP 1 region_id 7
testpmd> set port 0 queue-region UP 2 region_id 2
testpmd> se
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
Tested-by: Peng Yuan
- Tested Branch: dpdk-master
- Tested Commit: commit 8ced1542f7a356097c0b24bd1e08db670ff31b92
- OS: 4.8.6-300.fc25.x86_64
- GCC: gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
- CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
- NIC: X552/X557-AT 10GBASE-T [8086:15ad]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
Hardware:
dut: 10.240.176.192
tester: 10.240.176.191
X552/X557-AT 10g*2
Test steps:
Bind pf to igb_uio:
./usertools/dpdk-devbind.py -b igb_uio 03:00.0
add two vfs on dpdk pf, then bind the vfs to vfio-pci:
echo 2 >/sys/bus/pci/devices/:03:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 03:10.0 03:10.2
Start testpmd:
./x86_64-native-linuxapp-gcc/app/testpmd -c 1f -n 4 -m 1024 -w 03:00.0
--file-prefix=pf - -i --rxq=4 --txq=4
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf0 -n 4 -w 03:10.0
--file-prefix=vf0 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf00 -n 4 -w 03:10.2
--file-prefix=vf1 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
1. create filter rules,
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1309 / end
actions vf id 0 / end
Flow rule #0 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1308 / end
actions vf id 1 / end
Flow rule #1 created
2. send packets:
pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x309)/Raw('x' *
20)
pkt2 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x308)/Raw('x' *
20)
pkt3 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x307)/Raw('x' *
20)
pkt4 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x2, ECIDbase=0x309)/Raw('x' *
20)
verify pkt1 to vf0 queue0, pkt2 to vf1 queue0, pkt3 and pkt4 can't received by
pf and vfs.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
Sent: Wednesday, November 1, 2017 4:25 PM
To: dev@dpdk.org
Cc: Zhao1, Wei
Subject: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
The action for L2 tunnel should be VF, not QUEUE.
Fixes: 99e7003831c ("net/ixgbe: parse L2 tunnel filter")
Signed-off-by: Wei Zhao
---
drivers/net/ixgbe/ixgbe_flow.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 82fc705..1c5e103 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -1095,7 +1095,7 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* The first not void item can be E_TAG.
* The next not void item must be END.
* action:
- * The first not void action should be QUEUE.
+ * The first not void action should be VF.
* The next not void action should be END.
* pattern example:
* ITEMSpecMask
@@ -1116,7 +1116,7 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
const struct rte_flow_item_e_tag *e_tag_spec;
const struct rte_flow_item_e_tag *e_tag_mask;
const struct rte_flow_action *act;
- const struct rte_flow_action_queue *act_q;
+ const struct rte_flow_action_vf *act_vf;
if (!pattern) {
rte_flow_error_set(error, EINVAL,
@@ -1224,9 +1224,9 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- /* check if the first not void action is QUEUE. */
+ /* check if the first not void action is VF. */
act = next_no_void_action(actions, NULL);
- if (act->type != RTE_FLOW_ACTION_TYPE_QUEUE) {
+ if (act->type != RTE_FLOW_ACTION_TYPE_VF) {
memset(filter, 0, sizeof(struct rte_eth_l2_tunnel_conf));
rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION,
@@ -1234,8 +1234,8 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- act_q = (const struct rte_flow_action_queue *)act->conf;
- filter->pool = act_q->index;
+ act_vf = (const struct rte_flow_action_vf *)act->conf;
+ filter->pool = act_vf->id;
/* check if the next not void item is END */
act = next_no_void_action(actions, act); @@ -1260,6 +1260,8 @@
ixgbe_parse_l2_tn_filter(struct rte_eth_dev *dev, {
int ret = 0;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
+ uint16_t vf_num;
ret = cons_parse_l2_tn_filter(attr, pattern,
actions, l2_t
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
Tested-by: Peng Yuan
- Tested Branch: dpdk-master
- Tested Commit: 8ced1542f7a356097c0b24bd1e08db670ff31b92
- OS: 4.8.6-300.fc25.x86_64
- GCC: gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
- CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
- NIC: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T [8086:15ad]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
Hardware:
dut: 10.240.176.192
tester: 10.240.176.191
X552/X557-AT 10g*2
Test steps:
Bind pf to igb_uio:
./usertools/dpdk-devbind.py -b igb_uio 03:00.0
add two vfs on dpdk pf, then bind the vfs to vfio-pci:
echo 2 >/sys/bus/pci/devices/:03:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 03:10.0 03:10.2
Start testpmd:
./x86_64-native-linuxapp-gcc/app/testpmd -c 1f -n 4 -m 1024 -w 03:00.0
--file-prefix=pf - -i --rxq=4 --txq=4
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf0 -n 4 -w 03:10.0
--file-prefix=vf0 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf00 -n 4 -w 03:10.2
--file-prefix=vf1 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
1. create filter rules,
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1309 / end
actions vf id 0 / end
Flow rule #0 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1308 / end
actions vf id 1 / end
Flow rule #1 created
2. send packets:
pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x309)/Raw('x' *
20)
pkt2 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x308)/Raw('x' *
20)
pkt3 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x307)/Raw('x' *
20)
pkt4 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x2, ECIDbase=0x309)/Raw('x' *
20)
verify pkt1 to vf0 queue0, pkt2 to vf1 queue0, pkt3 and pkt4 can't received by
pf and vfs.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
Sent: Wednesday, November 1, 2017 4:25 PM
To: dev@dpdk.org
Cc: Zhao1, Wei
Subject: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
The action for L2 tunnel should be VF, not QUEUE.
Fixes: 99e7003831c ("net/ixgbe: parse L2 tunnel filter")
Signed-off-by: Wei Zhao
---
drivers/net/ixgbe/ixgbe_flow.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 82fc705..1c5e103 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -1095,7 +1095,7 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* The first not void item can be E_TAG.
* The next not void item must be END.
* action:
- * The first not void action should be QUEUE.
+ * The first not void action should be VF.
* The next not void action should be END.
* pattern example:
* ITEMSpecMask
@@ -1116,7 +1116,7 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
const struct rte_flow_item_e_tag *e_tag_spec;
const struct rte_flow_item_e_tag *e_tag_mask;
const struct rte_flow_action *act;
- const struct rte_flow_action_queue *act_q;
+ const struct rte_flow_action_vf *act_vf;
if (!pattern) {
rte_flow_error_set(error, EINVAL,
@@ -1224,9 +1224,9 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- /* check if the first not void action is QUEUE. */
+ /* check if the first not void action is VF. */
act = next_no_void_action(actions, NULL);
- if (act->type != RTE_FLOW_ACTION_TYPE_QUEUE) {
+ if (act->type != RTE_FLOW_ACTION_TYPE_VF) {
memset(filter, 0, sizeof(struct rte_eth_l2_tunnel_conf));
rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_ACTION,
@@ -1234,8 +1234,8 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- act_q = (const struct rte_flow_action_queue *)act->conf;
- filter->pool = act_q->index;
+ act_vf = (const struct rte_flow_action_vf *)act->conf;
+ filter->pool = act_vf->id;
/* check if the next not void item is END */
act = next_no_void_action(actions, act); @@ -1260,6 +1260,8 @@
ixgbe_parse_l2_tn_filter(struct rte_eth_dev *dev, {
int ret = 0;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
+ uint16_t vf_num;
ret = cons_parse_l2_tn_filter(attr, pattern,
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix filter parser error in L2 tunnel
Tested-by: Peng Yuan
- Tested Branch: dpdk-master
- Tested Commit: commit 6fb00f8baefa03b9cfd1b2dfc1787258b8459601
- OS: 4.8.6-300.fc25.x86_64
- GCC: gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
- CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
- NIC: X552/X557-AT 10GBASE-T [8086:15ad]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
Hardware:
dut: 10.240.176.192
tester: 10.240.176.191
X552/X557-AT 10g*2
Test steps:
Bind pf to igb_uio:
./usertools/dpdk-devbind.py -b igb_uio 03:00.0
add two vfs on dpdk pf, then bind the vfs to vfio-pci:
echo 2 >/sys/bus/pci/devices/:03:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 03:10.0 03:10.2
Start testpmd:
./x86_64-native-linuxapp-gcc/app/testpmd -c 1f -n 4 -m 1024 -w 03:00.0
--file-prefix=pf - -i --rxq=4 --txq=4
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf0 -n 4 -w 03:10.0
--file-prefix=vf0 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf00 -n 4 -w 03:10.2
--file-prefix=vf1 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
1. create filter rules,
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1309 / end actions
vf id 0 / end
Flow rule #0 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1308 / end actions
vf id 1 / end
Flow rule #1 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1307 / end actions
pf / end
Flow rule #2 created
2. send packets:
pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x309)/Raw('x' *
20)
pkt2 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x308)/Raw('x' *
20)
pkt3 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x307)/Raw('x' *
20)
pkt4 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x2, ECIDbase=0x309)/Raw('x' *
20)
verify pkt1 to vf0 queue0, pkt2 to vf1 queue0, pkt3 to pf queue 0, pkt4 can't
received by pf and vfs.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
Sent: Friday, November 3, 2017 3:39 PM
To: dev@dpdk.org
Cc: Zhao1, Wei
Subject: [dpdk-dev] [PATCH v4] net/ixgbe: fix filter parser error in L2 tunnel
The action for L2 tunnel should be VF or PF, not QUEUE.
Fixes: 99e7003831c ("net/ixgbe: parse L2 tunnel filter")
Signed-off-by: Wei Zhao
Acked-by: Wei Dai
---
v2:
-add vf id check.
v3:
-add action support for PF.
v4:
-fix action type check error
---
drivers/net/ixgbe/ixgbe_flow.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 82fc705..8bbc8b9 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -1095,7 +1095,7 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* The first not void item can be E_TAG.
* The next not void item must be END.
* action:
- * The first not void action should be QUEUE.
+ * The first not void action should be VF or PF.
* The next not void action should be END.
* pattern example:
* ITEMSpecMask
@@ -1106,7 +1106,8 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* item->last should be NULL.
*/
static int
-cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
+cons_parse_l2_tn_filter(struct rte_eth_dev *dev,
+ const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
struct rte_eth_l2_tunnel_conf *filter, @@ -1116,7
+1117,8 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
const struct rte_flow_item_e_tag *e_tag_spec;
const struct rte_flow_item_e_tag *e_tag_mask;
const struct rte_flow_action *act;
- const struct rte_flow_action_queue *act_q;
+ const struct rte_flow_action_vf *act_vf;
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
if (!pattern) {
rte_flow_error_set(error, EINVAL,
@@ -1224,9 +1226,10 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- /* check if the first not void action is QUEUE. */
+ /* check if the first not void action is VF or PF. */
act = next_no_void_action(actions, NULL);
- if (act->type != RTE_FLOW_ACTION_TYPE_QUEUE) {
+ if (act->type != RTE_FLOW_ACTION_TYPE_VF &&
+ act->type != RTE_FLOW_ACTION_TYPE_PF) {
memset(filter, 0, sizeof(struct rte_eth_l2_tunnel_conf));
rte_flow_error_set(error, EINVAL,
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix filter parser error in L2 tunnel
Tested-by: Peng Yuan
- Tested Branch: dpdk-master
- Tested Commit: commit 6fb00f8baefa03b9cfd1b2dfc1787258b8459601
- OS: 4.8.6-300.fc25.x86_64
- GCC: gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
- CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
- NIC: X552/X557-AT 10GBASE-T [8086:15ad]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
Hardware:
dut: 10.240.176.192
tester: 10.240.176.191
X552/X557-AT 10g*2
Test steps:
Bind pf to igb_uio:
./usertools/dpdk-devbind.py -b igb_uio 03:00.0
add two vfs on dpdk pf, then bind the vfs to vfio-pci:
echo 2 >/sys/bus/pci/devices/:03:00.0/max_vfs
./usertools/dpdk-devbind.py -b vfio-pci 03:10.0 03:10.2
Start testpmd:
./x86_64-native-linuxapp-gcc/app/testpmd -c 1f -n 4 -m 1024 -w 03:00.0
--file-prefix=pf - -i --rxq=4 --txq=4
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
testpmd> port config 0 l2-tunnel E-tag enable
testpmd> E-tag set forwarding on port 0
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf0 -n 4 -w 03:10.0
--file-prefix=vf0 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf00 -n 4 -w 03:10.2
--file-prefix=vf1 -m 1024 - -i --rxq=4 --txq=4 --disable-rss
testpmd> set fwd rxonly
testpmd> set verbose 1
testpmd> start
1. create filter rules,
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1309 / end actions
vf id 0 / end
Flow rule #0 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1308 / end actions
vf id 1 / end
Flow rule #1 created
testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1307 / end actions
pf / end
Flow rule #2 created
2. send packets:
pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x309)/Raw('x' *
20)
pkt2 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x308)/Raw('x' *
20)
pkt3 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1, ECIDbase=0x307)/Raw('x' *
20)
pkt4 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x2, ECIDbase=0x309)/Raw('x' *
20)
verify pkt1 to vf0 queue0, pkt2 to vf1 queue0, pkt3 to pf queue 0, pkt4 can't
received by pf and vfs.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
Sent: Friday, November 3, 2017 3:39 PM
To: dev@dpdk.org
Cc: Zhao1, Wei
Subject: [dpdk-dev] [PATCH v4] net/ixgbe: fix filter parser error in L2 tunnel
The action for L2 tunnel should be VF or PF, not QUEUE.
Fixes: 99e7003831c ("net/ixgbe: parse L2 tunnel filter")
Signed-off-by: Wei Zhao
Acked-by: Wei Dai
---
v2:
-add vf id check.
v3:
-add action support for PF.
v4:
-fix action type check error
---
drivers/net/ixgbe/ixgbe_flow.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
index 82fc705..8bbc8b9 100644
--- a/drivers/net/ixgbe/ixgbe_flow.c
+++ b/drivers/net/ixgbe/ixgbe_flow.c
@@ -1095,7 +1095,7 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* The first not void item can be E_TAG.
* The next not void item must be END.
* action:
- * The first not void action should be QUEUE.
+ * The first not void action should be VF or PF.
* The next not void action should be END.
* pattern example:
* ITEMSpecMask
@@ -1106,7 +1106,8 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
* item->last should be NULL.
*/
static int
-cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
+cons_parse_l2_tn_filter(struct rte_eth_dev *dev,
+ const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
struct rte_eth_l2_tunnel_conf *filter, @@ -1116,7
+1117,8 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
const struct rte_flow_item_e_tag *e_tag_spec;
const struct rte_flow_item_e_tag *e_tag_mask;
const struct rte_flow_action *act;
- const struct rte_flow_action_queue *act_q;
+ const struct rte_flow_action_vf *act_vf;
+ struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
if (!pattern) {
rte_flow_error_set(error, EINVAL,
@@ -1224,9 +1226,10 @@ cons_parse_l2_tn_filter(const struct rte_flow_attr *attr,
return -rte_errno;
}
- /* check if the first not void action is QUEUE. */
+ /* check if the first not void action is VF or PF. */
act = next_no_void_action(actions, NULL);
- if (act->type != RTE_FLOW_ACTION_TYPE_QUEUE) {
+ if (act->type != RTE_FLOW_ACTION_TYPE_VF &&
+ act->type != RTE_FLOW_ACTION_TYPE_PF) {
memset(filter, 0, s
Re: [dpdk-dev] [PATCH v7] net/i40e: determine number of queues per VF during run time
Tested-by: Peng,Yuan - Tested Branch: dpdk master - Tested Commit: 224374cc0e3ca44af5141fb7035a97f338d00c18 - OS: 4.5.5-300.fc24.x86_64 - GCC: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) - CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz - NIC: X710 for 10GbE SFP+ [8086:1572] - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 7 cases, 7 passed, 0 failed - Prerequisites command / instruction: 1.bind the pf port to dpdk driver:: ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 2. set up two vfs from the pf with DPDK driver:: echo 2 > /sys/bus/pci/devices/\:05\:00.0/max_vfs bind the two vfs to DPDK driver:: ./usertools/dpdk-devbind.py -b vfio-pci 05:02.0 05:02.1 - Case: Test case 1: set valid VF max queue number == 1. try the valid values 1:: ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 \ -w 05:00.0,queue-num-per-vf=1 --file-prefix=test1 \ --socket-mem 1024,1024 -- -i testpmd can be started normally without any wrong or error. 2. start VF testpmd with "--rxq=1 --txq=1", the number of rxq and txq is consistent with the configured VF max queue number:: ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf0 -n 4 -w 05:02.0 \ --file-prefix=test2 --socket-mem 1024,1024 -- -i --rxq=1 --txq=1 check the Max possible RX queues and TX queues is 1:: start forwarding, you can see the actual queue number is 1:: 3. repeat step1-2 with "queue-num-per-vf=2/4/8/16", and start VF testpmd with consistent rxq and txq number. check the max queue num and actual queue number is 2/4/8/16. Test case 2: set invalid VF max queue number 1. try the invalid value 0:: ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 \ -w 05:00.0,queue-num-per-vf=0 --file-prefix=test1 \ --socket-mem 1024,1024 -- -i testpmd started with "i40e_pf_parse_vf_queue_number_handler(): Wrong VF queue number = 0, it must be power of 2 and equal or less than 16 !, Now it is kept the value = 4" 2. start VF testpmd with "--rxq=4 --txq=4", the number of rxq and txq is consistent with the default VF max queue number:: check the Max possible RX queues and TX queues is 4:: start forwarding, you can see the actual queue number is 4:: 3. repeat step1-2 with "queue-num-per-vf=6/17/32", and start VF testpmd with default max rxq and txq number. check the max queue num and actual queue number is 4. Test case 3: set VF queue number in testpmd command-line options 1. set VF max queue number by PF:: ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 \ -w 05:00.0,queue-num-per-vf=8 --file-prefix=test1 \ --socket-mem 1024,1024 -- -i 2. start VF testpmd with "--rxq=3 --txq=3":: check the Max possible RX queues and TX queues is 8:: start forwarding, you can see the actual queue number is 3:: 3. quit the VF testpmd, then restart VF testpmd with "--rxq=9 --txq=9":: VF testpmd failed to start with the print:: Fail: nb_rxq(9) is greater than max_rx_queues(8) Test case 4: set VF queue number with testpmd function command == 1. set VF max queue number by PF:: ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 \ -w 05:00.0,queue-num-per-vf=8 --file-prefix=test1 \ --socket-mem 1024,1024 -- -i 2. start VF testpmd without setting "rxq" and "txq":: check the Max possible RX queues and TX queues is 8:: start forwarding, you can see the actual queue number is 1:: 3. set rx queue number and tx queue number with testpmd function command:: testpmd> port config all rxq 8 testpmd> port config all txq 8 start forwarding, you can see the actual queue number is 8:: 4. reset rx queue number and tx queue number to 9:: testpmd> port config all txq 9 Fail: nb_txq(9) is greater than max_tx_queues(8) testpmd> port config all rxq 9 Fail: nb_rxq(9) is greater than max_rx_queues(8) Failed to set it. Test case 5: VF max queue number when VF bound to kernel driver === 1. set VF max queue number to 2 by PF:: 2. check the VF0 and VF1 rxq and txq number is 2:: # ethtool -S enp5s2 3. repeat step1-2 with "queue-num-per-vf=1/4/8/16", check the rxq and txq number is 1/4/8/16. Test case 6: set VF max queue number with 32 VFs on one PF port === 1. set up 32 VFs from one PF with DPDK driver:: echo 32 > /sys/bus/pci/devices/\:05\:00.0/max_vfs bind the two of the VFs to DPDK driver:: ./usertools/dpdk-devbind.py -b vfio-pci 05:02.0 05:05.7 2. set VF max queue number to 16 by PF:: ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 \ -w 05:00.0,queue-num-per-
Re: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
Tested-by: Peng,Yuan
- Tested Branch: dpdk master dpdk-17.11-rc1
- Tested Commit: 87607f45bdecc31c33e9b7666b918dc685a10093
- OS: 4.4.0-62-generic
- GCC: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 2cases, 2passed, 0 failed
- Prerequisites command / instruction:
Two 40Gb Ethernet ports of the DUT are directly connected and link is up.
- Case:
Case1: loopback mode
enable loopback mode:
In dpdk/test/test/test_pmd_perf.c
set::
.lpbk_mode=1
#define MAX_TRAFFIC_BURST 32
then make test
start test::
./test/test/test -c f -n 4 -- -i
RTE>>pmd_perf_autotest
The final output of the test will be matrix of average cycles of IO used per
packet, and "Test OK" is printed out.
the peer port can't receive any packet.
case2: physical link mode
disable lookback mode:
In dpdk/test/test/test_pmd_perf.c
set::
.lpbk_mode=0
#define MAX_TRAFFIC_BURST 32
then make test
start test::
./test/test/test -c f -n 4 -- -i
RTE>>pmd_perf_autotest
there is not "Test OK" presented.
the peer port can receive all the 32 packets.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu
Sent: Monday, November 20, 2017 12:06 PM
To: dev@dpdk.org
Cc: Wu, Yanglong
Subject: [dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
According to loopback mode, setup loopback link or not.
If loopback link is setted, packets will be sent to rx_q from tx_q
directly.Loopback mode can be used to support testing task.
Signed-off-by: Yanglong Wu
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 1 +
drivers/net/i40e/i40e_ethdev.c | 12 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index c36da2a32..8171f877b 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -2128,6 +2128,7 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
/* Set Loopback mode (0x0618) */
struct i40e_aqc_set_lb_mode {
__le16 lb_mode;
+#define I40E_AQ_LB_MODE_NONE 0x0
#define I40E_AQ_LB_PHY_LOCAL 0x01
#define I40E_AQ_LB_PHY_REMOTE 0x02
#define I40E_AQ_LB_MAC_LOCAL 0x04
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index f40c463aa..2e6aa9d0d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2048,6 +2048,17 @@ i40e_dev_start(struct rte_eth_dev *dev)
}
}
+ /* Enable mac loopback mode */
+ if (hw->mac.type == I40E_MAC_XL710 &&
+ (dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_MODE_NONE ||
+ dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_PHY_LOCAL)) {
+ ret = i40e_aq_set_lb_modes(hw,
+ dev->data->dev_conf.lpbk_mode, NULL);
+ if (ret != I40E_SUCCESS) {
+ PMD_DRV_LOG(INFO, "fail to set loopback link");
+ goto err_up;
+ }
+ }
+
/* Apply link configure */
if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G |
--
2.11.0
Re: [dpdk-dev] [PATCH v2] net/i40e: support mac loopback
Tested-by: Peng,Yuan
- Tested Branch: dpdk master
- Tested Commit: e976052a1106153c93c802e5ffd2f6c8a29f239f
- OS: 4.4.0-62-generic
- GCC: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 2cases, 2passed, 0 failed
- Prerequisites command / instruction:
Two 40Gb Ethernet ports of the DUT are directly connected and link is up.
- Case:
Case1: loopback mode
enable loopback mode:
In dpdk/test/test/test_pmd_perf.c
set::
.lpbk_mode=1
#define MAX_TRAFFIC_BURST 32
then make test
./usertools/dpdk-devbind.py -b igb_uio 05:00.0
start test::
./test/test/test -c f -n 4 -- -i
RTE>>pmd_perf_autotest
The final output of the test will be matrix of average cycles of IO used per
packet, and "Test OK" is printed out.
the peer port can't receive any packet.
case2: physical link mode
disable lookback mode:
In dpdk/test/test/test_pmd_perf.c
set::
.lpbk_mode=0
#define MAX_TRAFFIC_BURST 32
then make test
start test::
./test/test/test -c f -n 4 -- -i
RTE>>pmd_perf_autotest
there is not "Test OK" presented.
the peer port can receive all the 32 packets.
When run the two test cases on XXV710 with same dpdk version, the cases passed
too.
-Original Message-
From: Wu, Yanglong
Sent: Wednesday, December 20, 2017 3:29 PM
To: dev@dpdk.org
Cc: Xing, Beilei ; Zhang, Helin ;
Peng, Yuan ; Wu, Yanglong
Subject: [PATCH v2] net/i40e: support mac loopback
According to loopback mode, setup loopback link or not.
If loopback link is setted, packets in tx will be sent to rx directly.
Loopback mode can be used to support testing task
Signed-off-by: Yanglong Wu
---
v2:
fix coding style issue
---
drivers/net/i40e/i40e_ethdev.c | 10 ++ drivers/net/i40e/i40e_ethdev.h
| 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 0739f65a8..e8bdb335a 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2047,6 +2047,16 @@ i40e_dev_start(struct rte_eth_dev *dev)
true, NULL);
}
}
+
+ /* Enable mac loopback mode */
+ if (dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_MODE_NONE ||
+ dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_PHY_LOCAL) {
+ ret = i40e_aq_set_lb_modes(hw, dev->data->dev_conf.lpbk_mode,
NULL);
+ if (ret != I40E_SUCCESS) {
+ PMD_DRV_LOG(ERR, "fail to set loopback link");
+ goto err_up;
+ }
+ }
/* Apply link configure */
if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M | diff
--git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h index
cd67453d1..2ad9858e4 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -61,7 +61,8 @@
#define I40E_NUM_MACADDR_MAX 64
/* Maximum number of VFs */
#define I40E_MAX_VF 128
-
+/*flag of no loopback*/
+#define I40E_AQ_LB_MODE_NONE 0x0
/*
* vlan_id is a 12 bit number.
* The VFTA array is actually a 4096 bit array, 128 of 32bit elements.
--
2.11.0
[dpdk-dev] [PATCH v3] i40e: fix olflags for vector Rx
Tested-by: Peng Yuan
- Test Commit: 04920e693a053a923f94c271ee68881756649cec
- OS/Kernel: Fedora 23/4.2.3
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- Total 1 cases, 1 passed, 0 failed.
Case1: read RSS HASH and RSS queue in the received packet. Passed.
DUT:
./tools/dpdk_nic_bind.py --bind=igb_uio :82:00.0 :82:00.1
./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i
--coremask=0xe --portmask=0x3 --rxq=16 --txq=16 --txqflags=0
testpmd> set verbose 8
testpmd> set fwd rxonly
testpmd> port stop all
testpmd> set_hash_global_config 0 toeplitz ipv4-udp enable port start
testpmd> all port config all rss udp start
tester:
scapy
>>> sendp([Ether(dst="00:00:00:00:01:00",
>>> src=get_if_hwaddr("enp132s0f1"))/IP(src="192.168.0.1",
>>> dst="192.168.0.2")/UDP(sport=1024,dport=1024)], iface="enp132s0f1")
If test in commit 04920e693a053a923f94c271ee68881756649cec (without the patch)
DUT receive the packet:
testpmd> port 0/queue 1: received 1 packets
src=00:00:00:00:01:01 - dst=00:00:00:00:01:00 - type=0x0800 - length=60 -
nb_segs=1 - FDIR matched hash=0xc3f2 ID=0x5263 Unknown packet type
- Receive queue=0x1
PKT_RX_FDIR
You can't find the RSS HASH and RSS queue
If test with [PATCH v3] i40e: fix olflags for vector Rx DUT receive the packet:
testpmd> port 0/queue 1: received 1 packets
src=00:00:00:00:01:01 - dst=00:00:00:00:01:00 - type=0x0800 - length=60 -
nb_segs=1 - RSS hash=0x5263c3f2 - RSS queue=0x1 - (outer) L2 type: ETHER -
(outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 type: UDP - Tunnel type: Unknown
- Inner L2 type: Unknown - Inner L3 type: Unknown - Inner L4 type: Unknown
- Receive queue=0x1
PKT_RX_RSS_HASH
You can check that RSS hash=0x5263c3f2 - RSS queue=0x1
The case was run in the default settings: CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
so the issue has been fixed.
Thank you.
Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhe Tao
Sent: Tuesday, June 14, 2016 1:24 PM
To: dev at dpdk.org
Cc: Tao, Zhe ; Wu, Jingjing
Subject: [dpdk-dev] [PATCH v3] i40e: fix olflags for vector Rx
Problem:
The flag for RSS and flow director is not set correctly in the vector Rx
function, so the upper layer APP which base on the related flags will not work
correctly.
Fix this problem by change the shuffle table. the original shuffle table is not
correct.
Fixes: 9ed94e5bb04e ("i40e: add vector Rx")
Signed-off-by: Zhe Tao
---
v2: Changed the comments according to the code change.
v3: Fixed the issues reported by check-git-log.sh.
drivers/net/i40e/i40e_rxtx_vec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx_vec.c b/drivers/net/i40e/i40e_rxtx_vec.c
index eef80d9..704924f 100644
--- a/drivers/net/i40e/i40e_rxtx_vec.c
+++ b/drivers/net/i40e/i40e_rxtx_vec.c
@@ -144,12 +144,13 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
uint64_t dword;
} vol;
- /* mask everything except rss and vlan flags
- *bit2 is for vlan tag, bits 13:12 for rss
- */
+ /* mask everything except RSS, flow director and VLAN flags
+* bit2 is for VLAN tag, bit11 for flow director indication
+* bit13:12 for RSS indication.
+*/
const __m128i rss_vlan_msk = _mm_set_epi16(
0x, 0x, 0x, 0x,
- 0x3004, 0x3004, 0x3004, 0x3004);
+ 0x3804, 0x3804, 0x3804, 0x3804);
/* map rss and vlan type to rss hash and vlan flag */
const __m128i vlan_flags = _mm_set_epi8(0, 0, 0, 0, @@ -159,8 +160,8 @@
desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
const __m128i rss_flags = _mm_set_epi8(0, 0, 0, 0,
0, 0, 0, 0,
- 0, 0, 0, 0,
- PKT_RX_FDIR, 0, PKT_RX_RSS_HASH, 0);
+ PKT_RX_RSS_HASH | PKT_RX_FDIR, PKT_RX_RSS_HASH, 0, 0,
+ 0, 0, PKT_RX_FDIR, 0);
vlan0 = _mm_unpackhi_epi16(descs[0], descs[1]);
vlan1 = _mm_unpackhi_epi16(descs[2], descs[3]); @@ -169,7 +170,7 @@
desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
vlan1 = _mm_and_si128(vlan0, rss_vlan_msk);
vlan0 = _mm_shuffle_epi8(vlan_flags, vlan1);
- rss = _mm_srli_epi16(vlan1, 12);
+ rss = _mm_srli_epi16(vlan1, 11);
rss = _mm_shuffle_epi8(rss_flags, rss);
vlan0 = _mm_or_si128(vlan0, rss);
--
2.1.4
[dpdk-dev] [PATCH v2] net/i40e: fix vsi removing from tailq when release
Tested-by: Peng Yuan
- Test Commit: 6baf0eca5cfa068621ee15605159523918109661
- OS/Kernel: 4.5.7-202.fc23.x86_64
- GCC: gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)
1. Bind 1 pf to igb_uio
2. use the pf to generate 2 VFs
3. rmmod i40evf
4. launch testpmd with PF with or without floating veb parameter, quit the
testpmd for several times, and never see the core dump So it can fix the "core
dump" issue.
Thank you.
Yuan.
-Original Message-
From: Wu, Jingjing
Sent: Monday, July 25, 2016 1:36 PM
To: Zhang, Helin
Cc: dev at dpdk.org; Wu, Jingjing ; Xing, Beilei
; Peng, Yuan
Subject: [PATCH v2] net/i40e: fix vsi removing from tailq when release
VSI structure need to be removed from TAILQ list when releasing.
But for the child VSI it will be removed again after the structure is freed. It
will cause core dump when the DPDK i40e using as PF host driver.
This patch fixes it to only remove child VSI from TAILQ before send adminq
command to remove it from hardware.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Fixes: 440499cf5376 ("net/i40e: support floating VEB")
Signed-off-by: Jingjing Wu
---
v2 change:
- add fix for floating veb case
drivers/net/i40e/i40e_ethdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 11a5804..d0aeb70 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4110,7 +4110,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, &vsi->veb->head, list, temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
- TAILQ_REMOVE(&vsi->veb->head, vsi_list, list);
}
i40e_veb_release(vsi->veb);
}
@@ -4119,7 +4118,6 @@ i40e_vsi_release(struct i40e_vsi *vsi)
TAILQ_FOREACH_SAFE(vsi_list, &vsi->floating_veb->head, list,
temp) {
if (i40e_vsi_release(vsi_list->vsi) != I40E_SUCCESS)
return -1;
- TAILQ_REMOVE(&vsi->floating_veb->head, vsi_list, list);
}
}
--
2.4.0
[dpdk-dev] [PATCH] i40e: fix link management
Tested-by: Peng Yuan
- Test Commit: 4cc20da049e0614eee99aeb097e648dbfa9fc655
- OS/Kernel: Fedora 23/4.2.3
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- Total 2 cases, 2 passed, 0 failed.
Case 1
After "set link-down port 0", the expection is" Link status: down"
DUT:
./dpdk_nic_bind.py -b igb_uio 8a:00.1
./testpmd -c 0x6 -n 4 -- -i --portmask=0x1 --port-topology=loop --txqflags=0
testpmd>set fwd mac
testpmd>start
testpmd>set link-down port 0
testpmd>show port info 0
it shows"link status: down"
TESTER:
ethtool enp138s0f0
it shows"Link detected: no"
case 2
after "port stop all", it will display " Link status: down"
DUT:
./dpdk_nic_bind.py -b igb_uio 8a:00.1
./testpmd -c 0x6 -n 4 -- -i --portmask=0x1 --port-topology=loop --txqflags=0
testpmd>set fwd mac
testpmd>start
testpmd>stop
testpmd>port stop all
testpmd>show port info 0
it shows"link status: down"
TESTER:
ethtool enp138s0f0
it shows"Link detected: no"
The link management runs normally.
Thanks
Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
Sent: Thursday, May 12, 2016 3:21 PM
To: Zhang, Helin
Cc: dev at dpdk.org; Wu, Jingjing ; Pei, Yulong
; Chilikin, Andrey
Subject: [dpdk-dev] [PATCH] i40e: fix link management
Previously, there was a known issue "On Intel? 40G Ethernet Controller stopping
the port does not really down the port link."
There were two reasons why the port is always kept up.
1. Old version Firmware would cause issue when call "Set PHY config command" on
40G NIC.
2. Because linux kernel i40e driver didn?t call "Set PHY config command" when
ifconfig up/down, and it assumes the link always up.
While ports are forced down when DPDK quit. So if the port is switched to
controlled by kernel driver, the port will not be up through "ifconfig
up".
This patch fixes this issue by reopening "Set PHY config command"
because:
1. New firmware issue is already fixed.
2. After DPDK quit, "ethtool -s autoneg on" can be used to turn on the
auto negotiation, and then port can be up through "ifconfig up" in new
version kernel i40e driver( >1.4.X ).
Fixes: 2f1e22817420 ("i40e: skip link control as firmware workaround")
Fixes: 16c979f9adf2 ("i40e: disable setting of PHY configuration")
Signed-off-by: Jingjing Wu
---
doc/guides/rel_notes/known_issues.rst | 19 -
drivers/net/i40e/i40e_ethdev.c| 72 +--
2 files changed, 60 insertions(+), 31 deletions(-)
diff --git a/doc/guides/rel_notes/known_issues.rst
b/doc/guides/rel_notes/known_issues.rst
index 923a202..489bb92 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -532,25 +532,6 @@ Cannot set link speed on Intel? 40G Ethernet controller
Poll Mode Driver (PMD).
-Stopping the port does not down the link on Intel? 40G Ethernet controller
---
-
-**Description**:
- On Intel? 40G Ethernet Controller stopping the port does not really down
the port link.
-
-**Implication**:
- The port link will be still up after stopping the port.
-
-**Resolution/Workaround**:
- None
-
-**Affected Environment/Platform**:
- All.
-
-**Driver/Module**:
- Poll Mode Driver (PMD).
-
-
Devices bound to igb_uio with VT-d enabled do not work on Linux kernel
3.15-3.17
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24777d5..4236d07 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1403,15 +1403,58 @@ i40e_parse_link_speeds(uint16_t link_speeds) }
static int
-i40e_phy_conf_link(__rte_unused struct i40e_hw *hw,
- __rte_unused uint8_t abilities,
- __rte_unused uint8_t force_speed)
-{
- /* Skip any phy config on both 10G and 40G interfaces, as a workaround
-* for the link control limitation of that all link control should be
-* handled by firmware. It should follow up if link control will be
-* opened to software driver in future firmware versions.
-*/
+i40e_phy_conf_link(struct i40e_hw *hw,
+ uint8_t abilities,
+ uint8_t force_speed)
+{
+ enum i40e_status_code status;
+ struct i40e_aq_get_phy_abilities_resp phy_ab;
+ struct i40e_aq_set_phy_config phy_conf;
+ const uint8_t mask = I40E_AQ_PHY_FLAG_PAUSE_TX |
+ I40E_AQ_PHY_FLAG_PAUSE_RX |
+ I40E_AQ_PHY_FLAG_PAUSE_RX |
+ I40E_AQ_PHY_FLAG_LOW_POWER;
+ const uint8_t advt = I40E_LINK
Re: [dpdk-dev] [PATCH] net/i40e: add warning info when no perfect RSS key
Tested-by: Peng Yuan
- Tested Branch: master
- Tested Commit: 239912fa798e6e671072ca7ff987afd74c1e506c
- OS: 4.13.9-300.fc27.x86_64
- GCC: gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation Device Fortville [8086:1583]
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 case1, 1 passed, 0 failed
- Case steps:
1. Bind the pf port to dpdk driver:
./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1
2. start testpmd:
./x86_64-native-linuxapp-gcc/app/testpmd --log-level=*:8 -c 1 -n 4 - -i
--nb-cores=8 --rxq=4 --txq=4 --port-topology=chained
3. set an invalid RSS-key
testpmd> flow create 0 ingress pattern end actions rss types ipv4-udp end key
67108863 / end
i40e_config_rss_filter(): Max of contiguous 4 PF queues are configured
i40e_config_rss_filter(): Warning! No perfect RSS key config for i40e, so use
default configuration
Flow rule #0 created
there is a device warning reported.
-Original Message-
From: Zhao1, Wei
Sent: Wednesday, March 20, 2019 11:31 AM
To: dev@dpdk.org
Cc: Peng, Yuan ; sta...@dpdk.org; Zhang, Qi Z
; Zhao1, Wei
Subject: [PATCH] net/i40e: add warning info when no perfect RSS key
There need a warning info when no perfect RSS key is config, so i40e will use
default key.
Fixes: ecad87d22383 ("net/i40e: move RSS to flow API")
Cc: sta...@dpdk.org
Signed-off-by: Wei Zhao
---
drivers/net/i40e/i40e_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index dca61f0..9235b08 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -12744,6 +12744,7 @@ i40e_config_rss_filter(struct i40e_pf *pf,
rss_conf.rss_key = (uint8_t *)rss_key_default;
rss_conf.rss_key_len = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
sizeof(uint32_t);
+ PMD_DRV_LOG(INFO, "Warning! No perfect RSS key config for i40e,
so
+use default configuration\n");
}
i40e_hw_rss_hash_set(pf, &rss_conf);
--
2.7.5
Re: [dpdk-dev] [PATCH] net/iavf: fix VF reset issue for FDIR rule
Test-by Peng, Yuan
-Original Message-
From: dev On Behalf Of Simei Su
Sent: Tuesday, April 28, 2020 1:49 PM
To: Zhang, Qi Z ; Ye, Xiaolong ;
Wu, Jingjing
Cc: dev@dpdk.org; Cao, Yahui ; Su, Simei
Subject: [dpdk-dev] [PATCH] net/iavf: fix VF reset issue for FDIR rule
After VF reset, FDIR rule still takes effect. To solve the issue, this patch
adds to flush all flows before flow uninit. VIRTCHNL sends message to PF by
Admin Queue, so flow flush should be implemented before Admin Queue shut down.
Fixes: c6ea8bd9f11f ("net/iavf: support generic flow")
Signed-off-by: Simei Su
---
drivers/net/iavf/iavf_ethdev.c | 1 +
drivers/net/iavf/iavf_generic_flow.c | 4 +---
drivers/net/iavf/iavf_generic_flow.h | 2 ++
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 117fbc5..e09efff 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -1431,6 +1431,7 @@ static int iavf_config_rx_queues_irqs(struct rte_eth_dev
*dev,
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
iavf_dev_stop(dev);
+ iavf_flow_flush(dev, NULL);
iavf_shutdown_adminq(hw);
/* disable uio intr before callback unregister */
rte_intr_disable(intr_handle);
diff --git a/drivers/net/iavf/iavf_generic_flow.c
b/drivers/net/iavf/iavf_generic_flow.c
index bca1ffe..8c66ac8 100644
--- a/drivers/net/iavf/iavf_generic_flow.c
+++ b/drivers/net/iavf/iavf_generic_flow.c
@@ -34,8 +34,6 @@ static struct rte_flow *iavf_flow_create(struct rte_eth_dev
*dev, static int iavf_flow_destroy(struct rte_eth_dev *dev,
struct rte_flow *flow,
struct rte_flow_error *error);
-static int iavf_flow_flush(struct rte_eth_dev *dev,
- struct rte_flow_error *error);
static int iavf_flow_query(struct rte_eth_dev *dev,
struct rte_flow *flow,
const struct rte_flow_action *actions, @@ -966,7 +964,7 @@
struct iavf_pattern_match_item *
return ret;
}
-static int
+int
iavf_flow_flush(struct rte_eth_dev *dev,
struct rte_flow_error *error)
{
diff --git a/drivers/net/iavf/iavf_generic_flow.h
b/drivers/net/iavf/iavf_generic_flow.h
index c41ca1b..978d071 100644
--- a/drivers/net/iavf/iavf_generic_flow.h
+++ b/drivers/net/iavf/iavf_generic_flow.h
@@ -306,6 +306,8 @@ struct iavf_flow_parser_node { void
iavf_register_flow_engine(struct iavf_flow_engine *engine); int
iavf_flow_init(struct iavf_adapter *ad); void iavf_flow_uninit(struct
iavf_adapter *ad);
+int iavf_flow_flush(struct rte_eth_dev *dev,
+ struct rte_flow_error *error);
int iavf_register_parser(struct iavf_flow_parser *parser,
struct iavf_adapter *ad);
void iavf_unregister_parser(struct iavf_flow_parser *parser,
--
1.8.3.1
[dpdk-dev] DPDK-20.05 RC2 day3 quick report
DPDK-20.05 RC2 day3 quick report * Totally create ~400+ new test cases for DPDK20.05 new features. * Totally 10207 cases, execution percentage is about 97%, pass rate is about 92%, 2 new issues are found till now, no critical issue new found. * Checked daily build, all pass. * Checked Basic NIC PMD(i40e, ixgbe, ice) PF & VF regression, new found 1 PF issue. * Checked virtio regression test, 1 bug is found. * Checked cryptodev and compressdev regression, no new issus found so far. * Checked NIC performance, no new issue found so far. * Checked ABI test, no new issue found so far. * Checked 20.05 new features: no new issue found so far. Thank you. Yuan.
[dpdk-dev] DPDK 20.05 RC2 Test Report
RC2 test is finished. Here is DPDK-20.05 RC2 validation report: * Totally create ~400+ new test cases for DPDK20.05 new features. * Totally run 10143 cases, debug progress is around 99%, pass rate is about 97%, 6 new issues are found, no critical issue found. * Checked daily build, all pass. * Checked Basic NIC PMD(i40e, ixgbe, ice) PF & VF regression: new found 1 PF issue and 1 VF issue. * Checked virtio regression test, 1 bug is found. * Checked cryptodev and compressdev regression, no new issus found. * Checked NIC performance, no new issue found. * Checked ABI test, no new issue found. * Checked 20.05 new features: found 3 new issues. Thank you. Yuan.
Re: [dpdk-dev] [PATCH] net/iavf: fix FDIR ID parsing issue after queue reconfigured
Test-by Peng, Yuan
-Original Message-
From: dev On Behalf Of Leyi Rong
Sent: Wednesday, May 20, 2020 2:40 PM
To: Wu, Jingjing ; Xing, Beilei ;
Ye, Xiaolong
Cc: dev@dpdk.org; Rong, Leyi
Subject: [dpdk-dev] [PATCH] net/iavf: fix FDIR ID parsing issue after queue
reconfigured
FDIR ID parsing will not be handled correctly after queue reconfigured, enable
FDIR ID parsing per Q regardless of fdir_ref_cnt to fix it.
Fixes: f71dbf852d46 ("net/iavf: add flow director enabled switch value")
Signed-off-by: Leyi Rong
---
drivers/net/iavf/iavf_rxtx.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h index
73968847f..59625a979 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -509,8 +509,8 @@ void iavf_fdir_rx_proc_enable(struct iavf_adapter *ad, bool
on) {
if (on) {
/* enable flow director processing */
- if (ad->fdir_ref_cnt++ == 0)
- FDIR_PROC_ENABLE_PER_QUEUE(ad, on);
+ FDIR_PROC_ENABLE_PER_QUEUE(ad, on);
+ ad->fdir_ref_cnt++;
} else {
if (ad->fdir_ref_cnt >= 1) {
ad->fdir_ref_cnt--;
--
2.17.1
[dpdk-dev] DPDK-20.05 RC3 day2 quick report
DPDK-20.05 RC3 day2 quick report * Totally create ~400+ new test cases for DPDK20.05 new features. * Totally 10203 cases, execution percentage is about 99%, pass rate is about 97%, 5 new issues are found till now, including a high level issue. * Checked build and compile, found 1 new issue, now fixed and verified. * Checked Basic NIC PMD(i40e, ixgbe, ice) PF & VF regression, new found 3 PF issue. * Checked virtio regression test, no new bug is found. * Checked cryptodev and compressdev regression, no new issus found so far. * Checked NIC performance, no new issue found so far. * Checked ABI test, no new issue found so far. * Checked 20.05 new features: 1 new issue found so far. Thank you. Yuan.
Re: [dpdk-dev] net/iavf: fix invalid flow access
Test-by Peng, Yuan
-Original Message-
From: dev On Behalf Of Jeff Guo
Sent: Friday, May 22, 2020 10:12 AM
To: Xing, Beilei ; Zhang, Qi Z ;
Wu, Jingjing ; Yang, Qiming
Cc: Ye, Xiaolong ; dev@dpdk.org; Guo, Jia
Subject: [dpdk-dev] net/iavf: fix invalid flow access
When hash init, the default rss rules would be added, while hash uninit, the
default rss rules should be deleted. Add the missing part in the hash uninit
process. Also add invalid flow checking func in iavf generic flow to avoid the
error of "Cannot access memory at address 0xXX" occur.
Fixes: 5ea614254332 ("net/iavf: fix VF reset for RSS")
Fixes: ff2d0c345c3b ("net/iavf: support generic flow API")
Signed-off-by: Jeff Guo
---
drivers/net/iavf/iavf_generic_flow.c | 24
drivers/net/iavf/iavf_hash.c | 12
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/net/iavf/iavf_generic_flow.c
b/drivers/net/iavf/iavf_generic_flow.c
index c0c67d0c7..b6c26c4fd 100644
--- a/drivers/net/iavf/iavf_generic_flow.c
+++ b/drivers/net/iavf/iavf_generic_flow.c
@@ -935,6 +935,22 @@ iavf_flow_create(struct rte_eth_dev *dev,
return flow;
}
+static bool
+iavf_flow_is_valid(struct rte_flow *flow) {
+ struct iavf_flow_engine *engine;
+ void *temp;
+
+ if (flow && flow->engine) {
+ TAILQ_FOREACH_SAFE(engine, &engine_list, node, temp) {
+ if (engine == flow->engine)
+ return true;
+ }
+ }
+
+ return false;
+}
+
static int
iavf_flow_destroy(struct rte_eth_dev *dev,
struct rte_flow *flow,
@@ -945,10 +961,10 @@ iavf_flow_destroy(struct rte_eth_dev *dev,
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(ad);
int ret = 0;
- if (!flow || !flow->engine || !flow->engine->destroy) {
+ if (!iavf_flow_is_valid(flow) || !flow->engine->destroy) {
rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_HANDLE,
- NULL, "Invalid flow");
+ NULL, "Invalid flow destroy");
return -rte_errno;
}
@@ -1002,10 +1018,10 @@ iavf_flow_query(struct rte_eth_dev *dev,
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
struct rte_flow_query_count *count = data;
- if (!flow || !flow->engine || !flow->engine->query_count) {
+ if (!iavf_flow_is_valid(flow) || !flow->engine->query_count) {
rte_flow_error_set(error, EINVAL,
RTE_FLOW_ERROR_TYPE_HANDLE,
- NULL, "Invalid flow");
+ NULL, "Invalid flow query");
return -rte_errno;
}
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c index
56ab170d8..af528863b 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -887,7 +887,7 @@ static struct iavf_flow_parser iavf_hash_parser = { };
static int
-iavf_hash_default_set(struct iavf_adapter *ad)
+iavf_hash_default_set(struct iavf_adapter *ad, bool add)
{
struct virtchnl_rss_cfg *rss_cfg;
uint16_t i;
@@ -902,9 +902,10 @@ iavf_hash_default_set(struct iavf_adapter *ad)
rss_cfg->proto_hdrs = *iavf_hash_default_hdrs[i];
rss_cfg->rss_algorithm = VIRTCHNL_RSS_ALG_TOEPLITZ_ASYMMETRIC;
- ret = iavf_add_del_rss_cfg(ad, rss_cfg, true);
+ ret = iavf_add_del_rss_cfg(ad, rss_cfg, add);
if (ret) {
- PMD_DRV_LOG(ERR, "fail to add RSS configure");
+ PMD_DRV_LOG(ERR, "fail to %s RSS configure",
+ add ? "add" : "delete");
rte_free(rss_cfg);
return ret;
}
@@ -941,7 +942,7 @@ iavf_hash_init(struct iavf_adapter *ad)
return ret;
}
- ret = iavf_hash_default_set(ad);
+ ret = iavf_hash_default_set(ad, true);
if (ret) {
PMD_DRV_LOG(ERR, "fail to set default RSS");
iavf_unregister_parser(parser, ad);
@@ -1222,6 +1223,9 @@ iavf_hash_destroy(__rte_unused struct iavf_adapter *ad,
static void iavf_hash_uninit(struct iavf_adapter *ad) {
+ if (iavf_hash_default_set(ad, false))
+ PMD_DRV_LOG(ERR, "fail to delete default RSS");
+
iavf_unregister_parser(&iavf_hash_parser, ad); }
--
2.20.1
[dpdk-dev] DPDK-20.05 RC3 quick report
DPDK-20.05 RC3 quick report * Totally create ~400+ new test cases for DPDK20.05 new features. * Totally 10203 cases, execution percentage is 100%, pass rate is about 99%, 8 new issues are found, including a high level issue(has been fixed and verified). * Checked build and compile, found 1 new issue, now fixed and verified. * Checked Basic NIC PMD(i40e, ixgbe, ice) PF & VF regression, new found 5 PF issue. * Checked virtio regression test, no new bug is found. * Checked cryptodev and compressdev regression, no new issus found so far. * Checked NIC performance, no new issue found so far. * Checked ABI test, no new issue found so far. * Checked 20.05 new features: 2 new issue found so far. Thank you. Yuan.
[dpdk-dev] DPDK-20.05 RC4 quick report
DPDK-20.05 RC4 quick report * Totally create ~400+ new test cases for DPDK20.05 new features. * Totally run 9976 cases, execution percentage is 100%, pass rate is about 99.5%, 2 new issues are found, no critical issues. * Checked build and compile, no new issue found. * Checked Basic NIC PMD(i40e, ixgbe, ice) PF & VF regression, new found 1 PF issue. * Checked virtio regression test, no new bug is found. * Checked cryptodev and compressdev regression, no new issus found so far. * Checked NIC performance, no new issue found so far. * Checked ABI test, no new issue found so far. * Checked 20.05 new features: 1 new issue found so far. Thank you. Yuan.
Re: [dpdk-dev] [PATCH 3/3] net/ice/base: force switch to use different recipe for
Test-by Peng, Yuan
-Original Message-
From: Zhao1, Wei
Sent: Friday, April 10, 2020 8:42 AM
To: dev@dpdk.org
Cc: Zhang, Qi Z ; Lu, Nannan ; Peng,
Yuan ; Zhao1, Wei
Subject: [PATCH 3/3] net/ice/base: force switch to use different recipe for
When we use profile rule as swicth rule to download, if we download 2 different
rules one by one, there will be rejection from function ice_aq_sw_rules(), for
example:
"flow create 0 priority 0 ingress pattern eth / ipv6 / ah / end actions queue
index 3 / end"
"flow create 0 priority 0 ingress pattern eth / ipv6 / esp / end actions queue
index 2 / end"
That is because the 2 rules has the same s_rule input set except action queue
index, so it will be rejected by hardware. So we have to use different recipes
for them.
Also, we need to add recipe_id to keep record of recipe index, which will be
used in rule remove, if not, there will be error when search recipe in function
ice_rem_adv_rule() if we create 2 or more profile rule.
For example:
"flow create 0 priority 0 ingress pattern eth / ipv4 / udp / pfcp s_field is 1
/ end actions queue index 4 / end"
"flow create 0 priority 0 ingress pattern eth / ipv4 / udp / pfcp s_field is 0
/ end actions queue index 5 / end"
then,
"flow flush 0"
you will find only the first rule will be delete, because ice_find_recp() will
always return recipe id of the first rule.
Signed-off-by: Wei Zhao
---
drivers/net/ice/base/ice_switch.c | 15 ++-
drivers/net/ice/base/ice_switch.h | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ice/base/ice_switch.c
b/drivers/net/ice/base/ice_switch.c
index bc0c368d7..d8eec7f51 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -4983,7 +4983,8 @@ static const struct ice_protocol_entry
ice_prot_id_tbl[ICE_PROTOCOL_LAST] = {
*
* Returns index of matching recipe, or ICE_MAX_NUM_RECIPES if not found.
*/
-static u16 ice_find_recp(struct ice_hw *hw, struct ice_prot_lkup_ext
*lkup_exts)
+static u16 ice_find_recp(struct ice_hw *hw, struct ice_prot_lkup_ext
*lkup_exts,
+enum ice_sw_tunnel_type tun_type)
{
bool refresh_required = true;
struct ice_sw_recipe *recp;
@@ -5042,7 +5043,10 @@ static u16 ice_find_recp(struct ice_hw *hw, struct
ice_prot_lkup_ext *lkup_exts)
/* If for "i"th recipe the found was never set to false
* then it means we found our match
*/
- if (found)
+ if (ice_is_prof_rule(tun_type) &&
+ tun_type == recp[i].tun_type && found)
+ return i; /* Return the recipe ID */
+ else if (!ice_is_prof_rule(tun_type) && found)
return i; /* Return the recipe ID */
}
}
@@ -5798,7 +5802,7 @@ ice_get_compat_fv_bitmap(struct ice_hw *hw, struct
ice_adv_rule_info *rinfo,
* if the rule type is a profile rule, that means that there no field value
* match required, in this case just a profile hit is required.
*/
-static bool ice_is_prof_rule(enum ice_sw_tunnel_type type)
+bool ice_is_prof_rule(enum ice_sw_tunnel_type type)
{
switch (type) {
case ICE_SW_TUN_PROFID_IPV6_ESP:
@@ -5952,11 +5956,12 @@ ice_add_adv_recipe(struct ice_hw *hw, struct
ice_adv_lkup_elem *lkups,
goto err_free_lkup_exts;
/* Look for a recipe which matches our requested fv / mask list */
- *rid = ice_find_recp(hw, lkup_exts);
+ *rid = ice_find_recp(hw, lkup_exts, rinfo->tun_type);
if (*rid < ICE_MAX_NUM_RECIPES)
/* Success if found a recipe that match the existing criteria */
goto err_unroll;
+ rm->tun_type = rinfo->tun_type;
/* Recipe we need does not exist, add a recipe */
status = ice_add_sw_recipe(hw, rm, match_tun, profiles);
if (status)
@@ -6873,7 +6878,7 @@ ice_rem_adv_rule(struct ice_hw *hw, struct
ice_adv_lkup_elem *lkups,
if (status)
return status;
- rid = ice_find_recp(hw, &lkup_exts);
+ rid = ice_find_recp(hw, &lkup_exts, rinfo->tun_type);
/* If did not find a recipe that match the existing criteria */
if (rid == ICE_MAX_NUM_RECIPES)
return ICE_ERR_PARAM;
diff --git a/drivers/net/ice/base/ice_switch.h
b/drivers/net/ice/base/ice_switch.h
index f7ae5c741..9666422f7 100644
--- a/drivers/net/ice/base/ice_switch.h
+++ b/drivers/net/ice/base/ice_switch.h
@@ -483,5 +483,6 @@ bool ice_is_vsi_valid(struct ice_hw *hw, u16 vsi_handle);
enum ice_status ice_replay_vsi_all_fltr(struct ice_hw *hw, u16 vsi_handle);
void ice_rm_all_sw_replay_rule_info(struct ice_hw *hw);
+bool ice_is_prof_rule(enum ice_sw_tunnel_type type);
#endif /* _ICE_SWITCH_H_ */
--
2.19.1
Re: [dpdk-dev] [dpdk-announce] release candidate 20.02-rc3
DPDK 20.02 RC3 Test Report from intel: Summary • Totally 9898 test cases for 20.02 RC3, 9629 cases are executed, 9428 test cases passed, 178 test cases failed, 23 test case blocked, Execution rate is 97.28%, pass rate is 97.91%. • Totally create ~278 new tests for DPDK20.02 new features. • New to create 9 issues from STV in RC3 till now, not include some issues have found and reported before RC3. • Met 1 build issue on Centos 7.4 with DPDK 20.02 RC3, now it has been fixed, and patch applied. Details: • Intel NIC PMD PF & VF regression: 99% executed, 0 critical issue and 1 high issue is tracked(verified). Function cases include rx/tx/forward packets, packet processing, jumboframe, dual vlan, filter cases and so on: 5 bugs found, no critical and high level. Performance cases such as l2fwd, l3fwd, single core and so on: no new bug is found. • Crypto cases include ipsec_gw cryptodev, fips cryptodev, l2fwd crypto, performance cases and so on: no critical and no high bugs found. • Vhost/virtio: PVP/loopback, qemu/virtio-user, multi-queue, dequeue zero copy cases and so on: 1 new medium bug is found. • Power relate cases, no new bug is found. • ABI test includes unit test, vhost and flow related tests. no new bug is found. • 20.02 new features include ABI test, L2tpv3, crypto_dev related new features and so no. no new bug is found. • Scecurity tests include Nic malformed to PF/VF, virtio, Compreqssion/cryptodev, power and invalid command line, all passed. Thanks. Yuan. -Original Message- From: dev On Behalf Of Thomas Monjalon Sent: Monday, February 17, 2020 5:59 AM To: annou...@dpdk.org Subject: [dpdk-dev] [dpdk-announce] release candidate 20.02-rc3 A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v20.02-rc3 121 patches were integrated. The release notes so far: http://doc.dpdk.org/guides/rel_notes/release_20_02.html Some deprecation notices might be added if reviewed on time. The -rc4 will include only bug fixes, doc and tooling. This next milestone is expected during next week. Please hurry up to do the last checks and bug fixes. You may share some release validation results by replying to this message (at dev@dpdk.org). If you are preparing the next release cycle, please send your v1 patches before the 20.05 proposal deadline, which will happen on March 18th. It is also time to build an estimated roadmap for the next cycles. Thank you everyone
[dpdk-dev] FW: 17.11.7-rc1 (LTS) patches review and test
Update the latest test status here.
-Original Message-
From: Yu, PingX
Sent: Thursday, September 12, 2019 2:37 PM
To: Yongseok Koh ; Ananyev, Konstantin
; as...@mellanox.com
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Ma, LihongX ; Li,
WenjieX A ; Wang, FengqinX ;
Peng, Yuan
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
All,
Update the latest test status here.
The critical bug has been fixed and we have re-tested all Intel key features.
Intel(R) Testing result lists here.
# Basic Intel(R) NIC testing
* PF(i40e): One bug found in 1st round test. 2nd round test pass after fixing
the bug. (see Bug1)
* PF(ixgbe): the same as PF(i40e).
* VF: Pass and no issue.
* Build or compile: One bug found in 1st round test. 2nd round test pass after
fixing the bug. (see Bug2)
* Intel NIC single core/NIC performance: Pass and no issue.
#Basic cryptodev and virtio testing
* vhost/virtio basic loopback, PVP and performance test: pass.
* cryptodev: 3 bugs are found(see bug statistic in below). (See Bug3,4 and 5)
Bugs statistic:
Bug1: make -C test/ failed. It blocked about 60 test cases for both PF(i40e)
and PF(ixgbe). Resolved by adding "#include " into test_rwlock.c.
Please decide whether submit a patch to DPDK or not.
Bug2: compile error on fc30. Patch is provided and validated pass. Need to
decide whether merge into DPDK or not.
Bug3: L2fwd: test_qat_h_AES_XCBC_MAC_auto failed. No progress yet.
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Bug4: Ipsec-gw_test forwarding failed with null crypto QAT. No progress yet.
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Bug5: Crypto: cryptodev_qat_autotest test failed. No progress yet.
39fb9500c42752a537588f7a203433ec4737fa1e is the first bad commit
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Regards,
Yu Ping
-Original Message-
From: Wang, FengqinX
Sent: Monday, August 26, 2019 3:12 PM
To: Yongseok Koh ; Ananyev, Konstantin
; as...@mellanox.com
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Yu, PingX ; Ma,
LihongX ; Li, WenjieX A
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
Add asafp in the loop due to Yongseok is longer working at Mellanox.
BRs, Vicky
-Original Message-
From: Wang, FengqinX
Sent: Monday, August 26, 2019 3:07 PM
To: 'Yongseok Koh' ; Ananyev, Konstantin
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Yu, PingX ; Ma,
LihongX ; Li, WenjieX A
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
Hi Yongseok, Konstantin,
There is one critical compile issue found, and below is the bad commit related
information, this issue has blocked most of unit tests which have used
dpdk/test/test, would you please help to fix this issue ASAP?
commit 29e08d740ffc1e0ed9e7a9bd25fb95714fac1070
Author: Joyce Kong
Date: Thu Jul 25 14:50:21 2019 +0800
test/rwlock: benchmark on all available cores
[ backported from upstream commit fe252fb695efa9deb95f2e6b7baf6f805996a5b0 ]
Add performance test on all available cores to benchmark
the scaling up performance of rw_lock.
Fixes: af75078fece3 ("first public release")
Suggested-by: Gavin Hu
Signed-off-by: Joyce Kong
Acked-by: Konstantin Ananyev
And below is the error message output:
test_rwlock.c: In function 'load_loop_fn':
test_rwlock.c:126:38: error: expected ')' before 'PRIu64'
printf("Core [%u] rwlock_data = %"PRIu64"\n", ^~
)
test_rwlock.c:126:19: error: format '%u' expects a matching 'unsigned int'
argument [-Werror=format=] printf("Core [%u] rwlock_data = %"PRIu64"\n", ~^
test_rwlock.c:126:36: error: spurious trailing '%' in format [-Werror=format=]
printf("Core [%u] rwlock_data = %"PRIu64"\n", ^
test_rwlock.c: In function 'test_rwlock_perf':
test_rwlock.c:160:31: error: expected ')' before 'PRIu64'
printf("Core [%u] count = %"PRIu64"\n", i, lock_count[i]); ^~
)
test_rwlock.c:160:18: error: format '%u' expects a matching 'unsigned int'
argument [-Werror=format=] printf("Core [%u] count = %"PRIu64"\n", i,
lock_count[i]); ~^
test_rwlock.c:160:29: error: spurious trailing '%' in format [-Werror=format=]
printf("Core [%u] count = %"PRIu64"\n", i, lock_count[i]); ^
test_rwlock.c:164:26: error: expected ')' before 'PRIu64'
printf("Total count = %"PRIu64"\n", total); ^~
)
test_rwlock.c:164:24: error: spurious trailing '%' in format [-Werror=format=]
pri
Re: [dpdk-dev] 17.11.7-rc1 (LTS) patches review and test
Bug 3-5 which are not fixed are medium.
Bug1 and bug2(high priority) have been fixed and verified, will the patches be
submitted?
-Original Message-
From: Peng, Yuan
Sent: Thursday, September 12, 2019 4:53 PM
To: dev@dpdk.org
Subject: FW: 17.11.7-rc1 (LTS) patches review and test
Update the latest test status here.
-Original Message-
From: Yu, PingX
Sent: Thursday, September 12, 2019 2:37 PM
To: Yongseok Koh ; Ananyev, Konstantin
; as...@mellanox.com
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Ma, LihongX ; Li,
WenjieX A ; Wang, FengqinX ;
Peng, Yuan
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
All,
Update the latest test status here.
The critical bug has been fixed and we have re-tested all Intel key features.
Intel(R) Testing result lists here.
# Basic Intel(R) NIC testing
* PF(i40e): One bug found in 1st round test. 2nd round test pass after fixing
the bug. (see Bug1)
* PF(ixgbe): the same as PF(i40e).
* VF: Pass and no issue.
* Build or compile: One bug found in 1st round test. 2nd round test pass after
fixing the bug. (see Bug2)
* Intel NIC single core/NIC performance: Pass and no issue.
#Basic cryptodev and virtio testing
* vhost/virtio basic loopback, PVP and performance test: pass.
* cryptodev: 3 bugs are found(see bug statistic in below). (See Bug3,4 and 5)
Bugs statistic:
Bug1: make -C test/ failed. It blocked about 60 test cases for both PF(i40e)
and PF(ixgbe). Resolved by adding "#include " into test_rwlock.c.
Please decide whether submit a patch to DPDK or not.
Bug2: compile error on fc30. Patch is provided and validated pass. Need to
decide whether merge into DPDK or not.
Bug3: L2fwd: test_qat_h_AES_XCBC_MAC_auto failed. No progress yet.
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Bug4: Ipsec-gw_test forwarding failed with null crypto QAT. No progress yet.
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Bug5: Crypto: cryptodev_qat_autotest test failed. No progress yet.
39fb9500c42752a537588f7a203433ec4737fa1e is the first bad commit
commit 39fb9500c42752a537588f7a203433ec4737fa1e
Author: Arek Kusztal
Date: Wed Dec 12 20:59:02 2018 +0100
Regards,
Yu Ping
-Original Message-
From: Wang, FengqinX
Sent: Monday, August 26, 2019 3:12 PM
To: Yongseok Koh ; Ananyev, Konstantin
; as...@mellanox.com
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Yu, PingX ; Ma,
LihongX ; Li, WenjieX A
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
Add asafp in the loop due to Yongseok is longer working at Mellanox.
BRs, Vicky
-Original Message-
From: Wang, FengqinX
Sent: Monday, August 26, 2019 3:07 PM
To: 'Yongseok Koh' ; Ananyev, Konstantin
Cc: Xu, Qian Q ; Lin, Xueqin ; Chen,
Zhaoyan ; O'Hare, Cathal ;
Yigit, Ferruh ; Yu, PingX ; Ma,
LihongX ; Li, WenjieX A
Subject: RE: 17.11.7-rc1 (LTS) patches review and test
Hi Yongseok, Konstantin,
There is one critical compile issue found, and below is the bad commit related
information, this issue has blocked most of unit tests which have used
dpdk/test/test, would you please help to fix this issue ASAP?
commit 29e08d740ffc1e0ed9e7a9bd25fb95714fac1070
Author: Joyce Kong
Date: Thu Jul 25 14:50:21 2019 +0800
test/rwlock: benchmark on all available cores
[ backported from upstream commit fe252fb695efa9deb95f2e6b7baf6f805996a5b0 ]
Add performance test on all available cores to benchmark
the scaling up performance of rw_lock.
Fixes: af75078fece3 ("first public release")
Suggested-by: Gavin Hu
Signed-off-by: Joyce Kong
Acked-by: Konstantin Ananyev
And below is the error message output:
test_rwlock.c: In function 'load_loop_fn':
test_rwlock.c:126:38: error: expected ')' before 'PRIu64'
printf("Core [%u] rwlock_data = %"PRIu64"\n", ^~
)
test_rwlock.c:126:19: error: format '%u' expects a matching 'unsigned int'
argument [-Werror=format=] printf("Core [%u] rwlock_data = %"PRIu64"\n", ~^
test_rwlock.c:126:36: error: spurious trailing '%' in format [-Werror=format=]
printf("Core [%u] rwlock_data = %"PRIu64"\n", ^
test_rwlock.c: In function 'test_rwlock_perf':
test_rwlock.c:160:31: error: expected ')' before 'PRIu64'
printf("Core [%u] count = %"PRIu64"\n", i, lock_count[i]); ^~
)
test_rwlock.c:160:18: error: format '%u' expects a matching 'unsigned int'
argument [-Werror=format=] printf("Core [%u] count = %"PRIu64"\n", i,
lock_count[i]); ~^
test_rwlock.c:160:29: error: spurious trailing '%' in format [-Werror=format=]
printf("Core [%u] count = %"PRI
[dpdk-dev] [PATCH] i40e: fix vlan filter in promiscuous mode
Tested-by: Peng Yuan
- Test Commit: a3f9ec846f9e7347d3a98da52256607345b4861d
- OS/Kernel: Fedora 23/4.2.3
- GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
- Total 7 cases, 7 passed, 0 failed.
pf
vf(pf_kerneldriver)
mac_filter
vlan_filter
mac+vlan_filter
mac_filter
vlan_filter
mac+vlan_filter
promisc off
PASS(dts case)
PASS
PASS
PASS(dts case)
PASS(dts case)
PASS
promisc on
N/A
PASS(dts case)
N/A
N/A
N/A
N/A
All the test cases I verified covers 7 scenarios as below table.
The issue happened in vlan_filter/promisc on, so I just describe the test steps
in this scenario.
Test_vlan_enable_receipt
1. Fortpark i40e driver, . /dpdk_nic_bind.py --bind=igb_uio :8a:00.1
:8a:00.3
2. ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 -n 4 -- -i
--portmask=0x1 --port-topology=loop --txqflags=0
3. Testpmd> set verbose 1
Testpmd> set fwd mac
Testpmd> vlan set filter on 0
Testpmd> vlan set strip off 0
Testpmd> rx_vlan add 51 0
Testpmd>start
4. Tester:
sendp([Ether(dst="00:00:00:00:03:15")/Dot1Q(vlan=51)/IP()/UDP()],iface="enp138s0f0",
count=1)
5. DUT can receive the packet, and check the vlan ID is correct.
6. Send packet with vlan0 and the packet can be received,
send packet without vlan and the packet can be received.
Send packet with wrong vlan(52/4095) and packet can't be receive.
Test_ vlan_disable_receipt
1. Testpmd>rx_vlan rm 51 0
Testpmd>start
2. Tester:
sendp([Ether(dst="00:00:00:00:03:15")/Dot1Q(vlan=51)/IP()/UDP()],iface="enp138s0f0",
count=1)
3. DUT can not receive the packet.
The vlan filter works normally.
Thanks
Yuan.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
Sent: Friday, May 27, 2016 4:06 PM
To: Zhang, Helin
Cc: dev at dpdk.org; Wu, Jingjing ; Pei, Yulong
Subject: [dpdk-dev] [PATCH] i40e: fix vlan filter in promiscuous mode
Vlan filter didn't work if promiscuous mode is enabled. That is because i40e
driver uses MAC VLAN table for the l2 filtering and internal switch. And the
vlan table is disabled by default, till the first time to add rule in vlan
table.
This patch fixed this issue to enable vlan filter by using vlan table.
Fixes: 4861cde46116 (i40e: new poll mode driver)
Signed-off-by: Jingjing Wu mailto:jingjing.wu at
intel.com>>
---
drivers/net/i40e/i40e_ethdev.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24777d5..0d91e29 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2443,12 +2443,16 @@ i40e_vlan_offload_set(struct rte_eth_dev *dev, int
mask) {
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
if (mask & ETH_VLAN_FILTER_MASK) {
- if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+if (dev->data->dev_conf.rxmode.hw_vlan_filter) {
+ i40e_aq_set_vsi_vlan_promisc(hw, vsi->seid, false,
NULL);
i40e_vsi_config_vlan_filter(vsi, TRUE);
- else
+} else {
+ i40e_aq_set_vsi_vlan_promisc(hw, vsi->seid, true,
NULL);
i40e_vsi_config_vlan_filter(vsi, FALSE);
+}
}
if (mask & ETH_VLAN_STRIP_MASK) {
@@ -5419,17 +5423,28 @@ i40e_set_vlan_filter(struct i40e_vsi *vsi,
uint16_t vlan_id, bool on)
{
uint32_t vid_idx, vid_bit;
+ struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
+ struct i40e_aqc_add_remove_vlan_element_data vlan_data = {0};
+ int ret;
if (vlan_id > ETH_VLAN_ID_MAX)
return;
vid_idx = I40E_VFTA_IDX(vlan_id);
vid_bit = I40E_VFTA_BIT(vlan_id);
+ vlan_data.vlan_tag = rte_cpu_to_le_16(vlan_id);
-if (on)
+ if (on) {
+ret = i40e_aq_add_vlan(hw, vsi->seid, &vlan_data, 1, NULL);
+if (ret != I40E_SUCCESS)
+ PMD_DRV_LOG(ERR, "Failed to add vlan filter");
vsi->vfta[vid_idx] |= vid_bit;
-else
+ } else {
+ret = i40e_aq_remove_vlan(hw, vsi->seid, &vlan_data, 1, NULL);
+if (ret != I40E_SUCCESS)
+ PMD_DRV_LOG(ERR, "Failed to remove vlan filter");
vsi->vfta[vid_idx] &= ~vid_bit;
+ }
}
/**
--
2.4.0
[dpdk-dev] [PATCH v8 3/3] i40e: add floating VEB extension support
Tested-by: Peng Yuan - Test Commit: f3625976474a595bfbdb44ad1c881b07d722a226 15ef663c2acb7ed576083f97cd2555fc9900c724 d0e57ebaf63fe240391dfafebd28f8e6559da899 - OS/Kernel: Fedora 23/4.2.3 - GCC: gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) - CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz - NIC: Fortville 2*40G - Total 6 cases,6 passed, 0 failed. There are three patch about the floating VEB feature, I put all of them, and just send one test-by. Here I listed the test case summary, you can get the detail steps from attachment. I run test cases according to my test plan, all the test cases passed. Test Case1: Floating VEB Inter-VM VF-VF === Summary: DPDK PF, then create 2VFs and 2VMs, assign one VF to one VM, say VF1 in VM1, VF2 in VM2, and make PF link down(the cable can be pluged out). VFs in VMs are running dpdk testpmd, VF1 send traffic, and set the packet's DEST MAC to VF2, check VF2 can receive the packets. Check Inter-VM VF-VF MAC switch when PF is link down as well as up. Test Case2: Floating VEB PF can't get traffic from VF DPDK PF, then create 1VF, assign VF1 to VM1, send traffic from VF1 to PF, then check PF will not see any traffic. Test Case3: Floating VEB VF can't receive traffic from outside world == DPDK PF, then create 1VF, assign VF1 to VM1, send traffic from tester to VF1, in floating mode, check VF1 can't receive traffic from tester. Test Case4: Floating VEB VF can not communicate with legacy VEB VF inter-VM == Summary: DPDK PF, then create 3VFs and 3VMs, assign one VF to one VM, say VF1 in VM1, VF3 in VM3, floating VEB; VF2 in VM2, lagecy VEB. Make PF link down(port stop all), VFs in VMs are running dpdk testpmd. 1. VF1 send traffic, and set the packet's DEST MAC to VF2, check VF2 can not receive the packets. 2. VF1 send traffic, and set the packet's DEST MAC to VF3, check VF3 can receive the packets. 3. VF2 send traffic, and set the packet's DEST MAC to VF1, check VF1 can not receive the packets. Check Inter-VM VF-VF MAC switch when PF is link down as well as up. Test Case5: PF can't get traffic from Floating VEB VF, but PF can get traffic from legacy VEB VF. DPDK PF, then create 2VF, assign VF1 to VM1, VF2 to VM2, set VF1 in floating VEB, VF2 in legacy VEB. 1. Send traffic from VF1 to PF, then check PF will not see any traffic; 2. Send traffic from VF2 to PF, then check PF will receive all the packets. Test Case6: Floating VEB VF can't receive traffic from outside world, while legacy VEB VF can receive traffic from outside world. == DPDK PF, then create 2VF, assign VF1 to VM1, assign VF2 to VM2, set VF1 in floating VEB, set VF2 in legacy VEB 1. send traffic from tester to VF1, check VF1 can't receive traffic from tester. 2. send traffic from tester to VF2, check VF2 can receive all the traffic from tester. Thanks! Yuan. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhe Tao Sent: Wednesday, May 25, 2016 1:28 AM To: dev at dpdk.org Cc: Tao, Zhe ; Wu, Jingjing Subject: [dpdk-dev] [PATCH v8 3/3] i40e: add floating VEB extension support To enable this feature, the user should pass a devargs parameter to the EAL like "-w 84:00.0,enable_floating=1", and the application will make sure the PMD will use the floating VEB feature for all the VFs created by this PF device. Also you can specifiy which VF need to connect to this floating veb using "floating_bitmap", every bit corresponding to one VF (e.g. bitn for VFn). Like "-w 84:00.0,enable_floating=1,floating_bitmap=1", means only the VF0 connect to the floating VEB, VF1 connect to the legacy VEB. Signed-off-by: Zhe Tao --- doc/guides/nics/i40e.rst | 5 +++- drivers/net/i40e/i40e_ethdev.c | 56 -- drivers/net/i40e/i40e_ethdev.h | 1 + drivers/net/i40e/i40e_pf.c | 3 ++- 4 files changed, 61 insertions(+), 4 deletions(-) diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index 49a0598..0919a96 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -372,4 +372,7 @@ FVL can support floating VEB feature. To enable this feature, the user should pass a devargs parameter to the EAL like "-w 84:00.0,enable_floating=1", and the application will make sure the PMD will use the floating VEB feature for all the VFs created by this PF device. - +Also you can specify which VF need to connect to this floating veb +using "floating_bitmap", every bit corresponding to one VF (e.g. bitn for VFn). +Lik
Re: [dpdk-dev] [PATCH] net/iavf: fix adding multicast MAC address
Test-by Peng, Yuan
-Original Message-
From: dev On Behalf Of Guinan Sun
Sent: Thursday, October 15, 2020 10:02 AM
To: dev@dpdk.org
Cc: Xing, Beilei ; Wu, Jingjing ;
Zhang, Qi Z ; Sun, GuinanX
Subject: [dpdk-dev] [PATCH] net/iavf: fix adding multicast MAC address
When the multicast address is added, it will flush previous addresses first,
and then add new ones.
So when adding an address that exceeds the upper limit causes a failure, you
need to add the previous address list back. This patch fixes the issue.
Fixes: 05e4c3aff35f ("net/iavf: support multicast configuration")
Signed-off-by: Guinan Sun
---
drivers/net/iavf/iavf_ethdev.c | 30 ++
drivers/net/iavf/iavf_vchnl.c | 3 ---
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index e68e3bc71..042edadd9 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -164,7 +164,14 @@ iavf_set_mc_addr_list(struct rte_eth_dev *dev,
struct iavf_info *vf = IAVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
struct iavf_adapter *adapter =
IAVF_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
- int err;
+ int err, temp_err;
+
+ if (mc_addrs_num > IAVF_NUM_MACADDR_MAX) {
+ PMD_DRV_LOG(ERR,
+ "can't add more than a limited number (%u) of
addresses.",
+ (uint32_t)IAVF_NUM_MACADDR_MAX);
+ return -EINVAL;
+ }
/* flush previous addresses */
err = iavf_add_del_mc_addr_list(adapter, vf->mc_addrs,
vf->mc_addrs_num, @@ -172,17 +179,24 @@ iavf_set_mc_addr_list(struct
rte_eth_dev *dev,
if (err)
return err;
- vf->mc_addrs_num = 0;
-
/* add new ones */
err = iavf_add_del_mc_addr_list(adapter, mc_addrs, mc_addrs_num, true);
- if (err)
- return err;
- vf->mc_addrs_num = mc_addrs_num;
- memcpy(vf->mc_addrs, mc_addrs, mc_addrs_num * sizeof(*mc_addrs));
+ if (err) {
+ /* When adding new addresses fail, need to add the
+* previous addresses back.
+*/
+ temp_err = iavf_add_del_mc_addr_list(adapter, vf->mc_addrs,
+vf->mc_addrs_num, true);
+ if (temp_err)
+ return temp_err;
+ } else {
+ vf->mc_addrs_num = mc_addrs_num;
+ memcpy(vf->mc_addrs,
+ mc_addrs, mc_addrs_num * sizeof(*mc_addrs));
+ }
- return 0;
+ return err;
}
static int
diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c
index db0b76876..a2295f879 100644
--- a/drivers/net/iavf/iavf_vchnl.c
+++ b/drivers/net/iavf/iavf_vchnl.c
@@ -1107,9 +1107,6 @@ iavf_add_del_mc_addr_list(struct iavf_adapter *adapter,
if (mc_addrs == NULL || mc_addrs_num == 0)
return 0;
- if (mc_addrs_num > IAVF_NUM_MACADDR_MAX)
- return -EINVAL;
-
list = (struct virtchnl_ether_addr_list *)cmd_buffer;
list->vsi_id = vf->vsi_res->vsi_id;
list->num_elements = mc_addrs_num;
--
2.13.6
Re: [dpdk-dev] [PATCH v1] net/ice: fix none GTPU TEID hash
Test-by Peng, Yuan
-Original Message-
From: dev On Behalf Of Jeff Guo
Sent: Friday, August 28, 2020 11:34 PM
To: Yang, Qiming ; Zhang, Qi Z
Cc: dev@dpdk.org; Guo, Jia
Subject: [dpdk-dev] [PATCH v1] net/ice: fix none GTPU TEID hash
GTPU TEID hash should only be enabled when ETH_RSS_GTPU is required.
Fixes: e7cc68c70736 ("net/ice: fix GTPU TEID hash")
Signed-off-by: Jeff Guo
---
drivers/net/ice/ice_hash.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c index
c0271dff5..61054557e 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -1151,7 +1151,10 @@ ice_hash_parse_action(struct ice_pattern_match_item
*pattern_match_item,
}
/* update hash field for gtpu eh/gtpu dwn/gtpu up. */
- if (hash_meta->pkt_hdr & ICE_FLOW_SEG_HDR_GTPU_EH) {
+ if (rss_type != ETH_RSS_GTPU) {
+ break;
+ } else if (hash_meta->pkt_hdr &
+ ICE_FLOW_SEG_HDR_GTPU_EH) {
hash_meta->hash_flds &=
~(BIT_ULL(ICE_FLOW_FIELD_IDX_GTPU_IP_TEID));
hash_meta->hash_flds |=
--
2.20.1
