From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1134-227.mail.aliyun.com (out1134-227.mail.aliyun.com [42.120.134.227]) by dpdk.org (Postfix) with ESMTP id D5418A6A for ; Sat, 5 Sep 2015 04:02:00 +0200 (CEST) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.3230379|-1; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03282; MF=jun.xiao@cloudnetengine.com; NM=1; PH=DW; RN=1; RT=1; SR=0; Received: from WS-web (jun.xiao@cloudnetengine.com[113.45.244.83]) by e02c03273.eu6 at Sat, 05 Sep 2015 10:01:57 +0800 Date: Sat, 05 Sep 2015 10:01:57 +0800 From: "Jun Xiao" To: "dev" Message-ID: <----Tc------lRRzc$fcf9aec7-4802-40bd-ae89-39fdd4fdd909@cloudnetengine.com> X-Mailer: Alimail-Mailagent revision 2704883 MIME-Version: 1.0 x-aliyun-mail-creator: W4_2704500_82MTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfOV81KSBBcHBsZVdlYktpdC82MDAuMi41IChLSFRNTCwgbGlrZSBHZWNrbykgVmVyc2lvbi83LjEuMiBTYWZhcmkvNTM3Ljg1LjExpd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] =?utf-8?q?CloudNetEngine_vSwitch_boosts_performance?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Jun Xiao List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2015 02:02:02 -0000 CloudNetEngine vSwitch boosts performance for both NFV and cloud use cases in = technical preview update 3.For the details, please refer to=C2=A0http://cloudn= etengine.com/en/blog/2015/09/05/cloudnetengine-vswitch-boosts-performance-clou= d-an/=0AOne key update:- CNE vSwitch is over 65% better than OVS-DPDK for smal= l packet size traffic. (It's about 10-20% advantage in technical preview updat= e 2)=0AAgain, thanks for all the contributions to make DPDK as such a great fo= undation!Jun Xiaowww.cloudnetengine.com >From nhorman@tuxdriver.com Sat Sep 5 04:21:43 2015 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id EA1192A66 for ; Sat, 5 Sep 2015 04:21:42 +0200 (CEST) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZY36p-00083v-8W; Fri, 04 Sep 2015 22:21:41 -0400 Date: Fri, 4 Sep 2015 22:21:27 -0400 From: Neil Horman To: Bruce Richardson Message-ID: <20150905022127.GA18405@neilslaptop.think-freely.org> References: <1441364514-24905-1-git-send-email-bernard.iremonger@intel.com> <20150904111850.GA10756@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150904111850.GA10756@bricha3-MOBL3> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 00/18] refactor eal driver registration code 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: Sat, 05 Sep 2015 02:21:43 -0000 On Fri, Sep 04, 2015 at 12:18:50PM +0100, Bruce Richardson wrote: > On Fri, Sep 04, 2015 at 12:01:36PM +0100, Bernard Iremonger wrote: > > At present the eal driver registration code is more complicated than it > > needs to be. > > > > This RFC proposes to simplify the eal driver registration code. > > > > Remove the type field from the eal driver structure. > > Refactor the eal driver registration code to use the name > > field in the eal driver structure instead of the type field. > > > > Modify all PMD's to use the modified eal driver structure. > > Initialise the name field in the eal driver structure > > in some PMD's where it is not initialised at present. > > > > > Hi, > > I don't think I like this approach very much. It seems very brittle to remove > the explicit type field and starting to rely on the drivers putting a prefix > in the name instead i.e. implicit typing. > > What is the major concern with marking drivers as virtual or physical? My thinking > is that we should keep the type field, just perhaps change PDEV to be more > descriptive in identifying the type of physical device, e.g. DEV_PCI. > The issue is largely philisophical. We shouldn't need to define the type of bus a driver is on in the init structure of a pmd. Instead we should register it dynamically during pmd initalization As you note, ennumerating the bus type (ie. PCI/USB/etc) is a step in the right direction, but it would be better to register that dynamically than to encode it in the data structure Neil > Regards, > /Bruce >