From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 94589AB03 for ; Mon, 16 Jun 2014 19:47:38 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Wwb0V-0003ys-9b; Mon, 16 Jun 2014 13:47:53 -0400 Date: Mon, 16 Jun 2014 13:47:46 -0400 From: Neil Horman To: "Richardson, Bruce" Message-ID: <20140616174746.GC15165@hmsreliant.think-freely.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59AF69C657FD0841A61C55336867B5B01AA368CE@IRSMSX103.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 17:47:38 -0000 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 able to figure > > out > > > a dependency tree for initialization of devices, based on the parsed 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 acceptible 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, probe, 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 visibility. > > > > How useful is this going to be? The more complicated the ethdev stacking being done, the better suited it is to being done via the C APIs, via code 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 bonded devices at runtime in place of physical ones, the bonded devices don't actually replace the physical ones, so some other application logic is needed to ensure 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 parameter, 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 set the appropriate bits in the portmask. Honestly? I don't know. As Stephen indicates the command line options might not be overly used, as its not always the best interface to select when building an application. But by the same token, not everyone is building an application 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're probably correct in that lots of people will use the C api to build bonded 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 porting 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. 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 hodgepodge of apis, all of which an application will have to be aware of to provide a full robust feature set. If --vdev stays, we should make it work for all the PMD's. Most might not 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 drop it and replace it with something better. Perhaps a configuration file interface would be good, so that the initialization of the pmds and the creation of interfaces is separated from the acutal application (thats actually a good 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. Neil