From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id E9D81B0C3 for ; Mon, 16 Jun 2014 20:08:05 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 16 Jun 2014 11:02:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,488,1400050800"; d="scan'208";a="529350725" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga001.jf.intel.com with ESMTP; 16 Jun 2014 11:08:14 -0700 Received: from irsmsx106.ger.corp.intel.com (163.33.3.31) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 19:07:52 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.58]) by IRSMSX106.ger.corp.intel.com ([169.254.8.14]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 19:07:52 +0100 From: "Richardson, Bruce" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes) Thread-Index: AQHPhyHLVoTzKnkjkEqwaO/aKtvfq5tvTRMAgAAR74CABASCgIAAI+oAgABkuZCAAAr7AIAAFDLw Date: Mon, 16 Jun 2014 18:07:51 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B01AA369EB@IRSMSX103.ger.corp.intel.com> References: <258914f35917ae07dddc991ac9726542964dce44.1402662300.git.declan.doherty@intel.com> <20140613160807.GD22451@hmsreliant.think-freely.org> <345C63BAECC1AD42A2EC8C63AFFC3ADC13D38EE9@IRSMSX101.ger.corp.intel.com> <20140613193815.GE22451@hmsreliant.think-freely.org> <345C63BAECC1AD42A2EC8C63AFFC3ADC13D39383@IRSMSX101.ger.corp.intel.com> <20140616110758.GA15165@hmsreliant.think-freely.org> <59AF69C657FD0841A61C55336867B5B01AA368CE@IRSMSX103.ger.corp.intel.com> <20140616174746.GC15165@hmsreliant.think-freely.org> In-Reply-To: <20140616174746.GC15165@hmsreliant.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes) 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: Mon, 16 Jun 2014 18:08:06 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Monday, June 16, 2014 10:48 AM > To: Richardson, Bruce > Cc: Doherty, Declan; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library > (librte_eal/librte_ether link bonding support changes) >=20 > On Mon, Jun 16, 2014 at 04:17:03PM +0000, Richardson, Bruce wrote: > > > > > > > -----Original Message----- > > <...snip...> > > > > this doesn't seem like an idea solution either. I'm not 100% clear = why > > > > rte_eal_pci_probe is currently called by the application code and = not > initiated > > > > from within rte_eal_dev_init, if this was the case we would be abl= e to > figure > > > out > > > > a dependency tree for initialization of devices, based on the parse= d input > > > > arguments without having extra user input to or multiple calls of > > > rte_eal_dev_init. > > > > > > > I agree, I think you should move it into its proper place within rte_= eal_init, > > > though I think multiple calls to rte_eal_dev_init is perfectly accept= ible in > > > this scenario. You certainly could parse the command line to build a > dependency > > > tree if you wish, though I don't think thats crruently overly complex= . The > current > > > dependency tree is static at (physical devices, virtual devices, prob= e, stacked > > > devices). If you need something more complex later, you can re-write= it > freely > > > as it will be an internal library mechanism with no external visibili= ty. > > > > > > > How useful is this going to be? The more complicated the ethdev stackin= g > being done, the better suited it is to being done via the C APIs, via cod= e which > can do analysis of the hardware and cores at runtime and make logical > decisions? After all, even if we do have applications being run to use bo= nded > devices at runtime in place of physical ones, the bonded devices don't ac= tually > replace the physical ones, so some other application logic is needed to e= nsure > that the application knows to only use the bonded devices. In most cases = simply > having a port-mask suffices, but not all apps will have a port-mask param= eter, > and for those that do, it introduces complexity for the user counting out > interfaces and trying to work out what ports will have what numbers to se= t the > appropriate bits in the portmask. >=20 > Honestly? I don't know. As Stephen indicates the command line options m= ight > not be overly used, as its not always the best interface to select when b= uilding > an application. But by the same token, not everyone is building an appli= cation > that needs dynamic configuration with DPDK. My main concern here is one = of > consistency, which is really what people look for in a package within a > distribution (i.e. Fedora, what I'm doing with the dpdk right now). You'r= e > probably correct in that lots of people will use the C api to build bonde= d > interfaces since its a new api and they won't have been using bonds yet. = But > I'm concerned that, with a distributed package, lots of people might also= be > porting legacy applications to use the DPDK, in which case they may very = well > want to create static configurations within the dpdk to lower their porti= ng > efforts. Those people may well be very turned off by the fact that some,= but > not all interfaces can use the command line to be configured. >=20 > In the end, its all about consistency in my mind. I get that the --vdev = command > line parameter perhaps isn't the most useful interface available, but its= whats > there. And if you start creating PMD's that use separate configuration > interfaces and abandon the ones before it, you'll wind up with a hodgepod= ge of > apis, all of which an application will have to be aware of to provide a f= ull > robust feature set. >=20 > If --vdev stays, we should make it work for all the PMD's. Most might no= t use > it, but some will, and those that do will appreciate the consistency you > provide. If it just doesn't make sense to keep it around anymore, lets d= rop it > and replace it with something better. Perhaps a configuration file inter= face > would be good, so that the initialization of the pmds and the creation of > interfaces is separated from the acutal application (thats actually a goo= d idea > I think, as it implies that all an application needs to know about is > interfaces, not how they are constructed or stacked). But lets not just = quietly > start abandoning stuff because its inconvienient. >=20 The config file idea is one that's probably worth considering for the futur= e. The thing about the vpmd option the assumption that all PMDs are equal. It = works well for creating pseudo-physical ethdevs, such as pcap, raw-socket o= r ring or other similar ethdevs, but I'm not sure it's a good abstraction f= or higher level functionality that we want to expose via an ethdev interfac= e. However, what to do for all these is not a decision we need to make for = 1.7 :-)