From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 7831B1B336 for ; Mon, 13 Nov 2017 10:41:33 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87A954901C; Mon, 13 Nov 2017 09:41:32 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 156AF60C2F; Mon, 13 Nov 2017 09:41:32 +0000 (UTC) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id E869F4BB78; Mon, 13 Nov 2017 09:41:31 +0000 (UTC) Date: Mon, 13 Nov 2017 04:41:31 -0500 (EST) From: Victor Kaplansky To: Thomas Monjalon Cc: Bruce Richardson , dev@dpdk.org, jingjing wu , Amnon Ilan , Tim Irnich , Georg Kunz , Gabor =?utf-8?Q?Hal=C3=A1sz?= , Mechthild Buescher , Franck Baudin , Jan Scheurich Message-ID: <1928354880.39298432.1510566091673.JavaMail.zimbra@redhat.com> In-Reply-To: <2833194.20UaxZ7Ebt@xps> References: <656367172.34323219.1509345665467.JavaMail.zimbra@redhat.com> <20171031101352.GB10572@bricha3-MOBL3.ger.corp.intel.com> <2833194.20UaxZ7Ebt@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.35.206.41, 10.4.195.13] Thread-Topic: testpmd: simulating noisy host environment Thread-Index: F5OyjeKnF+aMt+75uMZ9Q5lIkqlP3g== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 13 Nov 2017 09:41:32 +0000 (UTC) Subject: Re: [dpdk-dev] [RFC PATCH 0/4] testpmd: simulating noisy host environment X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:41:33 -0000 Hi, o testpmd is already the primary tool used by both DPDK developers, teste= rs and for performance evaluations. Performances reports are available on dpdk.org for each DPDK releases, on various NICs, so it is a common baseline. o testpmd is being used not only for NIC testing, but as a switch replace= ment on the host, by OPNFV VSPerf and FD.io CSIT o A single tool to cover all testing scenarios makes a lot of sense. It= =20 will make testpmd even more popular on communities using DPDK and surel= y promote DPDK. I fully understand the desire to keep testpmd as simple as possible, and we= can address this by making the additional functionality as modular as possible = in the source code. Or, if you prefer, we can create another tool even more ba= sic then current testpmd just as an example for educational purposes. What do you say? ----- Original Message ----- > From: "Thomas Monjalon" > To: "Bruce Richardson" , "Victor Kaplansky" <= vkaplans@redhat.com> > Cc: dev@dpdk.org, "jingjing wu" , "Amnon Ilan" , "Tim Irnich" > , "Georg Kunz" , "Gabor= Hal=C3=A1sz" , > "Mechthild Buescher" > Sent: Thursday, November 9, 2017 11:13:46 PM > Subject: Re: [dpdk-dev] [RFC PATCH 0/4] testpmd: simulating noisy host en= vironment >=20 > 31/10/2017 11:13, Bruce Richardson: > > On Mon, Oct 30, 2017 at 02:41:05AM -0400, Victor Kaplansky wrote: > > >=20 > > > This RFC patch propose enhancements to testpmd to simulate > > > more realistic behavior of a guest machine engaged in receiving > > > and sending packets performing Virtual Network Function (VNF). > > >=20 > > > The goal is to enable simple of measuring performance impact on cache= and > > > memory footprint utilization from various VNF co-located on the > > > same host machine. > > >=20 > > > This series of patches adds the new command line switches to > > > testpmd: > > >=20 > > Hi, > >=20 > > while I think this functionality is of use, I don't think it should go > > into testpmd. Testpmd is designed for testing NIC PMDs, and not as a > > general test tool, and is already complicated enough with lots of > > commandline options. For the task of testing VNF use-cases, I think a > > new separate app or example would be better. >=20 > Not sure. > If we need to mix the VNF simulation options with the NIC features > options (implemented in testpmd), then testpmd would be a good fit. >=20 > Please Victor, give your arguments to make the discussion progressing. >