From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 156C111DE for ; Fri, 17 Mar 2017 01:25:32 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP; 16 Mar 2017 17:25:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,174,1486454400"; d="scan'208";a="945262051" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 16 Mar 2017 17:25:30 -0700 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 16 Mar 2017 17:25:31 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.103]) by fmsmsx124.amr.corp.intel.com ([169.254.8.130]) with mapi id 14.03.0248.002; Thu, 16 Mar 2017 17:25:31 -0700 From: "Wiles, Keith" To: Julien Castets CC: "users@dpdk.org" Thread-Topic: [dpdk-users] Behavior of pktgen's "rate" option Thread-Index: AQHSnlnoG0YqDY2aWUK30Km5jZkBO6GYopqA Date: Fri, 17 Mar 2017 00:25:29 +0000 Message-ID: <0603B9A8-6CE9-45CA-AA98-4318E0F7E7EA@intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.31.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D12B11F82627A49B8B7FA3C65B0169D@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-users] Behavior of pktgen's "rate" option X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 00:25:33 -0000 > On Mar 16, 2017, at 9:33 PM, Julien Castets wrote: >=20 > I'm benchmarking my DPDK application with pktgen and I don't understand h= ow the > "rate" parameter works. >=20 > Let's run pktgen: >=20 > $> pktgen -l '0-11' --master-lcore=3D0 -w 03:00.0 -- -f > /home/jcastets/test.lua -m '[1].0' >=20 > (for information, my test.lua is at the bottom of this email) >=20 > Here, pktgen generates traffic with one core. >=20 >=20 > If I set the pktgen "rate" to "20" and the packet size to "64", I would e= xpect > to generate 20% of my NIC's max speed of traffic. In my case with my 40Gb= ps > NIC, I'd expect to generate 8Gbps of traffic. >=20 > And guess what, my expectations are good since with such configuration, p= ktgen > generates traffic as expected: 8Gbps. >=20 > However: >=20 > * If I run pktgen with 2 cores (-m '[1-2].0' instead of -m '[1].0'), pktg= en > generates 28Gbps. > * If I run pktgen with 1 core, keep the "rate" at "20" but set the pktsiz= e at > "128", pktgen generates 14Gbps (where I'd expect it to still generate 8G= bps). Be careful in how you setup and change the size of a packet. Changing the s= ize while Pktgen is running can lead to some weird performance. The problem= is the packets already in flight are not changed to the new size or they a= re stuck on the TX done queue. The new TX flush API needs to be added to th= e PMDs and then in Pktgen I can flush all of the buffers back to the mempoo= l and then alter the size of the mbuf. You did not state the version of Pkt= gen you are using, as DPDK 16.11 added some support for pktgen to locate an= d update all of the mbuf, I think that is kind of a hack on my part. The code in Pktgen takes your rate and packet size to determine the number = of packets to send at a given rate to obtain you desired rate. I thought th= e calculation accounted for the number of TX cores, but maybe that is a bu= g. I would have expected 16Gbps in the two core case if I did not account f= or that config. I do not have direct access to the machine to verify the co= de. Try stopping the traffic before changing any of the configs, changing the r= ate should work while Pktgen is sending. The problem is if the size of cont= ent needs to change the system should be halted. Also if you want to do a s= ome more debugging, try quiting Pktgen between configurations and see if th= at works better. It is not what I intended on the usage of Pktgen is to qui= t all of the time. I will try to have a look this weekend when I get back home. >=20 >=20 > Can please anyone clarify how the rate/pktsize/cores relation works? >=20 >=20 >=20 > ### test.lua >=20 > pktgen.stop("all"); > pktgen.reset("all"); > pktgen.clear("all"); >=20 > pktgen.src_mac("all", "start", "3c:fd:fe:a2:2c:88"); > pktgen.dst_mac("all", "start", "3c:fd:fe:a2:2b:b0"); >=20 > pktgen.src_ip("all", "start", "192.168.1.1"); > pktgen.src_ip("all", "min", "0.0.0.0"); > pktgen.src_ip("all", "inc", "0.0.0.0"); > pktgen.src_ip("all", "max", "0.0.0.0"); >=20 > pktgen.src_port("all", "start", 1234); > pktgen.src_port("all", "min", 1234); > pktgen.src_port("all", "inc", 1); > pktgen.src_port("all", "max", 4096); >=20 > pktgen.ip_proto("all", "udp"); >=20 >=20 > pktgen.dst_ip("all", "start", "192.168.100.1"); > pktgen.dst_ip("all", "min", "192.168.100.1"); > pktgen.dst_ip("all", "inc", "0.0.0.1"); > pktgen.dst_ip("all", "max", "192.168.100.99"); >=20 > pktgen.dst_port("all", "start", 1234); > pktgen.dst_port("all", "min", 0); > pktgen.dst_port("all", "inc", 0); > pktgen.dst_port("all", "max", 0); >=20 >=20 > pktgen.vlan("all", "off"); > pktgen.vlan_id("all", "start", 1024); > pktgen.vlan_id("all", "min", 1); > pktgen.vlan_id("all", "inc", 5); > pktgen.vlan_id("all", "max", 3100); >=20 > pktgen.pkt_size("all", "start", 128); -- this is the parameter I'm > trying to adjust > pktgen.pkt_size("all", "min", 0); > pktgen.pkt_size("all", "inc", 0); > pktgen.pkt_size("all", "max", 0); >=20 > pktgen.set_range("all", "on"); >=20 > pktgen.set("all", "count", 0); -- count 0 is forever > pktgen.set("all", "rate", 20); -- this is the parameter I'm trying to adj= ust > pktgen.start("all"); >=20 > --=20 > Julien Castets Regards, Keith