From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by dpdk.org (Postfix) with ESMTP id 5E85A106B for ; Mon, 23 Mar 2015 16:51:53 +0100 (CET) Received: by oier21 with SMTP id r21so144183459oie.1 for ; Mon, 23 Mar 2015 08:51:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=pcOQRsTWY80ellPHG0kFlmTjSF2RpU9e2E96cVQFPYM=; b=lA8jJ/uH78Wmu6AEdB24/zY3O2RnYbXzVhPlCUR0Pp2/h89CaXO77ykOIESiS92fce 1nqd4rvlOftYEXFOp2tdQiNoVfm3h7TW878p2He3T2SVTb9JCe9knk+b3KcN4uDv5uyn +PdQuRJ7IeJMybuj/khaEAOdZ7ZCELQvovJ3T/oI3XHXAvSpeikBniKFZsJryNQvrsk1 WkwJlrfK6dYh8L2neqkHCJXRbUSzjN1TNgp9IpspsyTCMVHB0Iq5AbCQzpqdc/D5Etyd rsKJBtI9qkjG9uZ4gecYkHPfoUtwUrHAefAu2fSQQ/S6JukRtoO0wEGIOrBVBS4lFiDC p+ww== X-Gm-Message-State: ALoCoQnaALl+uOJzEYGTzSLCH/EDUiqQsYm1DO1An1OpnIkkpSWU7WPgNKX4YTivmik9t2K7hUdm X-Received: by 10.202.61.87 with SMTP id k84mr71733480oia.70.1427125912775; Mon, 23 Mar 2015 08:51:52 -0700 (PDT) Received: from [172.27.33.191] ([208.123.73.28]) by mx.google.com with ESMTPSA id km2sm180131obb.23.2015.03.23.08.51.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 08:51:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Matt Smith In-Reply-To: Date: Mon, 23 Mar 2015 10:51:21 -0500 Message-Id: <10590839-9A46-4199-BBB3-EB6D36FE1F6E@netgate.com> References: <41BFB154-C54A-4712-99A3-279EC6C02685@netgate.com> To: "Wiles, Keith" X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" 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: Mon, 23 Mar 2015 15:51:53 -0000 > On Mar 14, 2015, at 1:33 PM, Wiles, Keith = wrote: >=20 > Hi Matt, >=20 > On 3/14/15, 8:47 AM, "Wiles, Keith" > wrote: >=20 >> Hi Matt >>=20 >> On 3/13/15, 3:49 PM, "Matt Smith" wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>> I=C2=B9ve 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. >>>=20 >>> 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. >>>=20 >>> 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=C2=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: >>>=20 >>> const struct rte_eth_conf port_conf =3D { >>> .rxmode =3D { >>> .mq_mode =3D ETH_MQ_RX_RSS, >>>=20 >>> 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. >>>=20 >>> 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? >>=20 >> 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 =C5=92missed=C2=B9 frames at the wire. The RX counter is the = number of missed >> frames. >>=20 >> Thanks for the input >> ++Keith >=20 > I added code to hopefully setup the correct RX/TX conf values. The = HEAD of > the Pktgen-DPDK v2.8.4 should build and work with DPDK 1.8.0 or = 2.0.0-rc1. > I did still see some RX errors and reduced bit rate, but the traffic = does > not stop on my machine. Please give version 2.8.4 a try and let me = know if > you still see problems. >=20 > Regards, > ++Keith Hi Keith, Sorry for the delay in responding, I have been out of town. Thanks for your attention to the problem. I pulled the latest code from = git and moved to the pktgen-2.8.4 tag. I had one issue building: CC pktgen-port-cfg.o /root/dpdk/pktgen-dpdk/app/pktgen-port-cfg.c: In function = =E2=80=98pktgen_config_ports=E2=80=99: /root/dpdk/pktgen-dpdk/app/pktgen-port-cfg.c:300:11: error: variable = =E2=80=98k=E2=80=99 set but not used [-Werror=3Dunused-but-set-variable] uint64_t k; ^ cc1: all warnings being treated as errors make[2]: *** [pktgen-port-cfg.o] Error 1 make[1]: *** [all] Error 2 make: *** [app] Error 2 I prepended '__attribute__((unused))=E2=80=99 to the declaration of k = and then I was able to build successfully. I did not see any receive = errors running the updated binary. So once I got past the initial build = problem, the issue seems to be resolved. Thanks, -Matt