From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 67BB1E6D for ; Fri, 22 Apr 2016 07:52:01 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP; 21 Apr 2016 22:52:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,516,1455004800"; d="scan'208";a="964061569" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 21 Apr 2016 22:52:01 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 21 Apr 2016 22:51:58 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX102.amr.corp.intel.com (10.18.124.200) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 21 Apr 2016 22:51:58 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.229]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.155]) with mapi id 14.03.0248.002; Fri, 22 Apr 2016 13:51:56 +0800 From: "Wang, Zhihong" To: "Richardson, Bruce" , Thomas Monjalon CC: "dev@dpdk.org" , "De Lara Guarch, Pablo" Thread-Topic: [dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd Thread-Index: AQHRm5Fx+stu0PIj/Ee/h5c6FqWlfp+TqkQAgAASdwCAAbqrMA== Date: Fri, 22 Apr 2016 05:51:55 +0000 Message-ID: <8F6C2BD409508844A0EFC19955BE09410342D1E0@SHSMSX103.ccr.corp.intel.com> References: <1461192195-104070-1-git-send-email-zhihong.wang@intel.com> <1946900.ocWSxO32dE@xps13> <20160421110018.GB11224@bricha3-MOBL3> In-Reply-To: <20160421110018.GB11224@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTQ5ZGVkYmItMzJhYi00Mzc2LWIxOTYtMjBmNmY1NmNhYjFkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjRhN1RUUFpsOHRwSlhHRUxhRjIxS0t6TnYxbEg5SCtSVTY3TUd5WEg5MFU9In0= x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd 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, 22 Apr 2016 05:52:02 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Thursday, April 21, 2016 7:00 PM > To: Thomas Monjalon > Cc: Wang, Zhihong ; dev@dpdk.org; De Lara Guarch, > Pablo > Subject: Re: [dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd >=20 > On Thu, Apr 21, 2016 at 11:54:12AM +0200, Thomas Monjalon wrote: > > 2016-04-20 18:43, Zhihong Wang: > > > This RFC patch proposes a general purpose forwarding engine in testpm= d > > > namely "portfwd", to enable performance analysis and tuning for poll = mode > > > drivers in vSwitching scenarios. > > > > > > > > > Problem statement > > > ----------------- > > > > > > vSwitching is more I/O bound in a lot of cases since there are a lot = of > > > LLC/cross-core memory accesses. > > > > > > In order to reveal memory/cache behavior in real usage scenarios and = enable > > > efficient performance analysis and tuning for vSwitching, DPDK needs = a > > > sample application that supports traffic flow close to real deploymen= t, > > > e.g. multi-tenancy, service chaining. > > > > > > There is a vhost sample application currently to enable simple vSwitc= hing > > > scenarios, it comes with several limitations: > > > > > > 1) Traffic flow is too simple and not flexible > > > > > > 2) Switching based on MAC/VLAN only > > > > > > 3) Not enough performance metrics > > > > > > > > > Proposed solution > > > ----------------- > > > > > > The testpmd sample application is a good choice, it's a powerful poll= mode > > > driver management framework hosts various forwarding engine. > > > > Not sure it is a good choice. > > The goal of testpmd is to test every PMD features. > > How far can we go in adding some stack processing while keeping it > > easily maintainable? >=20 > I was thinking the exact same thing. Would it not be better to enhance th= e > existing vhost example application to remove the limitations you call out= above? > I don't particularly like the idea of introducing protocol awareness into= testpmd > for IP forwarding, for instance. Hi Bruce, I understand the concern. Like I mentioned in the original thread, this utility is not for vSwitching in particular, it's just adding more forwarding setup capabilities in testp= md. testpmd composes of separated components: 1) pmd management framework 2) forwarding engines: a) traffic setup b) forwarding function When adding a new fwd engine, only the new traffic setup function and forwarding function (maybe cmd handlers too) are added, no existing things are touched. So it doesn't make it harder to maintain. It doesn't change the current behavior at all, by default it's still iofwd, the user can switch to portfwd only when flexible forwarding rules are needed. I understand that testpmd was positioned to provide test framework for pmds, and it's no harm to keep it that way. But I think testpmd has already become a widely used tool to setup performance and functional test in both DPDK and OVS-DPDK community. It can do more with simple changes like this. There're benefits to enhance forwarding capabilities of testpmd, like, people can build up DPDK performance/functional test more easily, in both host and guest; also it eliminates overheads in apps like OVS to test what DPDK can provide in real scenarios for analysis. With the vhost pmd feature, testpmd has become a vSwitch already, we just need to add more forwarding setup capability to make use of it. If we modify the current vhost sample to do this, then we basically just re-implement what testpmd has already provided all over again, which introduces duplicated efforts and increases maintenance work because what's changed in testpmd may need to go into that sample too. Thanks Zhihong >=20 > Regards, > /Bruce