[dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G

Wiles, Keith keith.wiles at intel.com
Sat Jan 30 02:23:42 CET 2016


Regards,
Keith


From: Moon-Sang Lee <sang0627 at gmail.com<mailto:sang0627 at gmail.com>>
Date: Wednesday, January 27, 2016 at 1:50 AM
To: "Keith Wiles (Intel)" <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>
Cc: Laurent GUERBY <laurent at guerby.net<mailto:laurent at guerby.net>>, "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Errors Rx count increasing while pktgen doing nothing on Intel 82598EB 10G


Laurent, have you resolved this problem?
I'm using the same NIC as yours (i.e. Intel 82598EB 10G NIC) and faced the same problem as you.
Here is parts of my log and it says that PMD cannot enable RX queue for my NIC.
I'm using DPDK 2.2.0 and used 'null' for the 4th parameter in calling rte_eth_rx_queue_setup().
(i.e. 'null' parameter provides the default rx_conf value.)

Thanks.

The problem I found with the increasing RX errors is because a stats register was being read that does not exist in that given chipset and removing that register read would eliminate the false errors you were seeing. Here is part of the email I sent to Laurent.

Hi Laurent,

Well, it appears the problem is on the ixgbe driver the fccrc and fclast hw stats are not supported on 82598 only the 82599+ devices.

On t3 you can look at the ixgbe_ethdev.c code I modified to remove these two stats, which caused ierrors to increase. You can also revert any changes in Pktgen to master as they did not help fix any thing. Sorry is it 6 am and I need to sleep some, I could not sleep tonight, so you I was able to debug the problem. Please remove the debug code in the ixgbe driver if you like as well and move that change to t1 machine. I will report this to the list later.

The performance of pktgen/DPDK was not being effected by these counters.

Thanks
++Keith





APP: initialising port 0 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5f27258040 sw_sc_ring=0x7f5f27257b00 hw_ring=0x7f5f27258580 dma_addr=0x41f458580
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f27245940 hw_ring=0x7f5f27247980 dma_addr=0x41f447980
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f272337c0 hw_ring=0x7f5f27235800 dma_addr=0x41f435800
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 4 (port=0).
PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
APP: port 0 has started
APP: port 0 has entered in promiscuous mode
APP: port 0 initialization is done.
KNI: pci: 09:00:00 8086:10c7
APP: kni allocation is done for port 0.
APP: initialising port 1 ...
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5f27222dc0 sw_sc_ring=0x7f5f27222880 hw_ring=0x7f5f27223300 dma_addr=0x41f423300
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f272106c0 hw_ring=0x7f5f27212700 dma_addr=0x41f412700
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5f271fe540 hw_ring=0x7f5f27200580 dma_addr=0x41f400580
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_set_rx_function(): Vector rx enabled, please make sure RX burst size no less than 4 (port=1).
PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
APP: port 1 has started
APP: port 1 has entered in promiscuous mode
APP: port 1 initialization is done.
KNI: pci: 0a:00:00 8086:10c7
APP: kni allocation is done for port 1.

checking link status
.done
Port 0 Link Up - speed 10000 Mbps - full-duplex
Port 1 Link Up - speed 10000 Mbps - full-duplex


On Mon, Dec 28, 2015 at 5:28 AM, Wiles, Keith <keith.wiles at intel.com<mailto:keith.wiles at intel.com>> wrote:
On 12/27/15, 2:09 PM, "Laurent GUERBY" <laurent at guerby.net<mailto:laurent at guerby.net>> wrote:

>On Sun, 2015-12-27 at 19:43 +0000, Wiles, Keith wrote:
>> On 12/27/15, 12:31 PM, "dev on behalf of Laurent GUERBY" <dev-bounces at dpdk.org<mailto:dev-bounces at dpdk.org> on behalf of laurent at guerby.net<mailto:laurent at guerby.net>> wrote:
>>
>> >Hi,
>> >
>> >I reported today an issue when using Pktgen-DPDK:
>> >https://github.com/pktgen/Pktgen-DPDK/issues/52
>> >
>> >But I think it's more in DPDK than pktgen
>> >
>> >two identical machines with SFP+ DA cable between them
>> >DPDK 2.2.0 from tarball
>> >Pktgen-DPDK from git
>> >two identical machines:
>> >core i7 2600 (sandy bridge 4C/8T), HT disabled in the BIOS
>> >ASUS P8H67-M PRO BIOS 3904 (latest available)
>> >Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port
>> >Network Connection (rev 01)
>> >01:00.0 0200: 8086:10f1 (rev 01)
>> >    Subsystem: 8086:a21f
>> >boot kernel 3.16 unbutu 14.04 with isolcpus=2,3,4
>> >
>> >When launching pktgen even with no TX asked the Errors RX counters keeps
>> >going up by about 7.4 millions per second:
>> >
>> >Errors Rx/Tx : 7471857054/0
>> >
>> >In the log I get "Could not enable Rx Queue", might be the
>> >source of the issue?
>> >
>> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 0
>> >PMD: ixgbe_dev_rx_queue_start(): Could not enable Rx Queue 1
>> >
>> >When sending traffic  single UDP src/dst/IP/MAC the setup
>> >reaches 14204188 pps 64 bytes, the error counter is also
>> >increasing.
>> >
>> >Any idea what to look for?
>>
>> One more suggestion is to run test_pmd on one machine and something
>> like iperf on the other to verify the DPDK is working correct, which I
>> assume will be true. Not sure the RX errors are reported in the
>> test_pmd or you could use the l3fwd application too.
>
>Ok, I will check the test_pmd documentation and try to do this test: I'm
>just starting on DPDK :).
>
>> Please also send me the 'lspci | grep Ethernet’ output.
>
>I included one line in my original email above (plus extract of lspci
>-vn), here is the full output of the command:
>
>01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
>Dual Port Network Connection (rev 01)
>01:00.1 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF
>Dual Port Network Connection (rev 01)
>05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>
>(The realtek is used only for internet connectivity).
>
>> Also send me the command line.
>
>On the first machine t1 :
>root at t1:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
>-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t1-t3.pkt -N
>
>And on the other machine t3:
>root at t3:~/pktgen-dpdk# ./app/app/x86_64-native-linuxapp-gcc/pktgen \
>-c e -n 1 --proc-type auto -- -m '[2:3].1' -P -f t3-t1.pkt -N

You need to always start with port numbering for Pktgen with zero.

Change the [2:3].1 to [2:3].0 the reason is you removed one of the two ports and Pktgen starts port counting from zero for the first available port :-)

Sorry, I did not spot that sooner.
>
>The two "-f" pkt files are attached to this email, I do "start 1"
>manually at the pktgen prompt.
>
>Thanks for your time,
>
>Sincerely,
>
>Laurent
>
>
>> >
>> >Laurent
>> >
>> >
>>
>>
>> Regards,
>> Keith
>>
>>
>>
>>
>
>


Regards,
Keith







--
Moon-Sang Lee, SW Engineer
Email: sang0627 at gmail.com<mailto:sang0627 at gmail.com>
Wisdom begins in wonder. *Socrates*


More information about the dev mailing list