Re: [dpdk-dev] pktgen rx errors with intel 82599

["Wiles, Keith" <keith.wiles@intel.com>]

Hi Matt

On 3/13/15, 3:49 PM, "Matt Smith" <mgsmith@netgate.com> wrote:

>
>Hi,
>
>I¹ve been using DPDK pktgen 2.8.0 (built against DPDK 1.8.0 libraries) to
>send traffic on a server using an Intel 82599 (X520-2). Traffic gets sent
>out port 1 through another server which also an Intel 82599 installed and
>is forwarded back into port 0. When I send using a single source and
>destination IP address, this works fine and packets arrive on port 0 at
>close to the maximum line rate.
>
>If I change port 1 to range mode and send traffic from a range of source
>IP addresses to a single destination IP address, for a second or two the
>display indicates that some packets were received on port 0 but then the
>rate of received packets on the display goes to 0 and all incoming
>packets on port 0 are registered as rx errors.
>
>The server that traffic is being forwarded through is running the
>ip_pipeline example app. I ruled this out as the source of the problem by
>sending directly from port 1 to port 0 of the pktgen box. The issue still
>occurs when the traffic is not being forwarded through the other box.
>Since ip_pipeline is able to receive the packets and forward them without
>getting rx errors and it¹s running with the same model of NIC as pktgen
>is using, I checked to see if there were any differences in
>initialization of the rx port between ip_pipeline and pktgen. I noticed
>that pktgen has a setting that ip_pipeline doesn't:
>
>const struct rte_eth_conf port_conf = {
>    .rxmode = {
>    .mq_mode = ETH_MQ_RX_RSS,
>
>If I comment out the .mq_mode setting and rebuild pktgen, the problem no
>longer occurs and I now receive packets on port 0 at near line rate when
>testing from a range of source addresses.
>
>I recall reading in the past that if a receive queue fills up on an 82599
>, that receiving stalls for all of the other queues and no more packets
>can be received. Could that be happening with pktgen? Is there any
>debugging I can do to help track it down?

I have seen this problem on some platforms a few times and it looks like
you may have found a possible solution to the problem. I will have to look
into the change and see if this is the problem, but it does seem to
suggest this may be the issue. When the port gets into this state the port
receives the number mbufs matching the number of descriptors and the rest
are Œmissed¹ frames at the wire. The RX counter is the number of missed
frames.

Thanks for the input
++Keith
>
>The command line I have been launching pktgen with is:
>
>pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1
>
>Thanks,
>
>-Matt Smith
>
>
>
>
>