>
>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.

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

Reply via email to