From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6C2FD5A8B for ; Sat, 14 Mar 2015 14:47:35 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 14 Mar 2015 06:47:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,400,1422950400"; d="scan'208";a="467248771" Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by FMSMGA003.fm.intel.com with ESMTP; 14 Mar 2015 06:40:33 -0700 Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX110.amr.corp.intel.com (10.22.240.8) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 14 Mar 2015 06:47:33 -0700 Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by ORSMSX112.amr.corp.intel.com (10.22.240.13) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 14 Mar 2015 06:47:33 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.22]) by FMSMSX151.amr.corp.intel.com ([169.254.7.46]) with mapi id 14.03.0195.001; Sat, 14 Mar 2015 06:47:27 -0700 From: "Wiles, Keith" To: Matt Smith , "dev@dpdk.org" Thread-Topic: [dpdk-dev] pktgen rx errors with intel 82599 Thread-Index: AQHQXc8zjngq0zftAUeSjXRZLHur+Z0cILUA Date: Sat, 14 Mar 2015 13:47:26 +0000 Message-ID: References: <41BFB154-C54A-4712-99A3-279EC6C02685@netgate.com> In-Reply-To: <41BFB154-C54A-4712-99A3-279EC6C02685@netgate.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.44.182] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1B0498B212CCF249BE4AAA41520AB0E7@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] pktgen rx errors with intel 82599 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 13:47:35 -0000 Hi Matt On 3/13/15, 3:49 PM, "Matt Smith" wrote: > >Hi, > >I=B9ve been using DPDK pktgen 2.8.0 (built against DPDK 1.8.0 libraries) t= o >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=B9s 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 =3D { > .rxmode =3D { > .mq_mode =3D 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 =8Cmissed=B9 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 > > > > >