From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by dpdk.org (Postfix) with ESMTP id A321B7F1C for ; Fri, 13 Mar 2015 21:49:03 +0100 (CET) Received: by oiav1 with SMTP id v1so18576872oia.3 for ; Fri, 13 Mar 2015 13:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=I1xdPSPjOqPrYh//yndUGNY0etdKRfVQOiYfn99nqdk=; b=e49eaK13dCaNKAzmyBBFA5E7IKN4OIH+x77ocd6CYEXebQ5dEhQh4xe3JW7nuL6Sxp 8EmtUjM0hGjrTDbm8JqegA6AeeIyDm1QxMzejjxOHIetqEM2EQ2h3PeKnP8BQxjidPWU rm2SPm6Tt105UWX37FhzUw/F9f5U6V3+PADzzENE0Mt5t0wPs5k8ZvyaUdi+6z3UTbnA 9FgNBJYb+i+a06fraw6kRztt01IuChG4PKRGS9H+477JlCOXOBRvdr7a8t9Lr3ambbw/ oRbnGFO0z59JKZqVar3YgRyB7Je+ts+7Yls1mGQ+ru2/Z9w/OHqYFR+G0fy+RMftPqNm DQKw== X-Gm-Message-State: ALoCoQk3WaxYRMBWkGb/Ad+lagvb/hXUuyhpUt8I1XGSee6Q4r4uPGfjhDRn9l2uCaLtS9s52SKv X-Received: by 10.202.2.79 with SMTP id 76mr7985684oic.111.1426279743103; Fri, 13 Mar 2015 13:49:03 -0700 (PDT) Received: from [172.16.0.54] (cpe-72-182-3-41.austin.res.rr.com. [72.182.3.41]) by mx.google.com with ESMTPSA id n6sm1001973oep.16.2015.03.13.13.49.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 13:49:02 -0700 (PDT) From: Matt Smith Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Mar 2015 15:49:01 -0500 Message-Id: <41BFB154-C54A-4712-99A3-279EC6C02685@netgate.com> To: dev@dpdk.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Subject: [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: Fri, 13 Mar 2015 20:49:04 -0000 Hi, I=E2=80=99ve 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. 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=E2=80=99s 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? The command line I have been launching pktgen with is:=20 pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1 Thanks, -Matt Smith