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 26280594E for ; Thu, 5 May 2016 13:39:02 +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 1ayHcL-0007Wr-8Q; Thu, 05 May 2016 07:38:58 -0400 Date: Thu, 5 May 2016 07:38:47 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, David Marchand , Stephen Hemminger , "Richardson, Bruce" , Panu Matilainen Message-ID: <20160505113847.GA7585@hmsreliant.think-freely.org> References: <1461692391-30093-1-git-send-email-nhorman@tuxdriver.com> <20160504114305.GA27687@hmsreliant.think-freely.org> <2684085.G5NnXQEQ33@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2684085.G5NnXQEQ33@xps13> User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: Re: [dpdk-dev] [RFC PATCH 0/4]: Implement module information export 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: Thu, 05 May 2016 11:39:02 -0000 On Wed, May 04, 2016 at 11:16:42PM +0200, Thomas Monjalon wrote: > This discussion requires more opinions. > Please everybody, READ and COMMENT. Thanks > > If it is not enough visible, a new thread could be started later. > > 2016-05-04 07:43, Neil Horman: > > On Wed, May 04, 2016 at 10:24:18AM +0200, David Marchand wrote: > > > On Tue, May 3, 2016 at 1:57 PM, Neil Horman wrote: > > > >> This approach has a few pros and cons: > > > >> > > > >> pros: > > > >> 1) Its simple, and doesn't require extra infrastructure to implement. E.g. we > > > >> don't need a new tool to extract driver information and emit the C code to build > > > >> the binary data for the special section, nor do we need a custom linker script > > > >> to link said special section in place > > > >> > > > >> 2) Its stable. Because the marker symbols are explicitly exported, this > > > >> approach is resilient against stripping. > > It is a good point. We need something resilient against stripping. > > > > >> cons: > > > >> 1) It creates an artifact in that PMD_REGISTER_DRIVER has to be used in one > > > >> compilation unit per DSO. As an example em and igb effectively merge two > > > >> drivers into one DSO, and the uses of PMD_REGISTER_DRIVER occur in two separate > > > >> C files for the same single linked DSO. Because of the use of the __COUNTER__ > > > >> macro we get multiple definitions of the same marker symbols. > > > >> > > > >> I would make the argument that the downside of the above artifact isn't that big > > > >> a deal. Traditionally in other projects a unit like a module (or DSO in our > > > >> case) only ever codifies a single driver (e.g. module_init() in the linux kernel > > > >> is only ever used once per built module). If we have code like igb/em that > > > >> shares some core code, we should build the shared code to object files and link > > > >> them twice, once to an em.so pmd and again to an igb.so pmd. > > It is also a problem for compilation units having PF and VF drivers. > Thats exactly the problem in the two cases I encountered. The common code between the PF and VF drivers was handled by simply building the whole driver together, which is problematic because it make both drivers bigger than they need to be. But its somewhat moot, as the problem is orthogonal to this one if we have to go with a 'special section' approach to implementing this. > > > >> But regardless, I thought I would propose this to see what you all thought of > > > >> it. > > Thanks for proposing. > > > > - This implementation does not support binaries, so it is not suitable > > > for people who don't want dso, this is partially why I used bfd rather > > > than just dlopen. > > > > If you're statically linking an application, you should know what hardware you > > support already. Its going to be very hard, if not impossible to develop a > > robust solution that works with static binaries (the prior solutions don't work > > consistently with static binaries either). I really think the static solution > > needs to just be built into the application (i.e. the application needs to add a > > command line option to dump out the pci id's that are registered). > > No, we need a tool to know what are the supported devices before running > the application (e.g. for binding). > This tool should not behave differently depending of how DPDK was compiled > (static or shared). > Very well. > [...] > > > - How does it behave if we strip the dsos ? > > > > I described this above, its invariant to stripping, because the symbols for each > > pmd are explicitly exported, so strip doesn't touch the symbols that pmdinfo > > keys off of. > > > [...] > > > - The tool output format is not script friendly from my pov. > > > > Don't think it really needs to be script friendly, it was meant to provide human > > readable output, but script friendly output can be added easily enough if you > > want. > > Yes it needs to be script friendly. > Thats easy enough. > It appears that we must agree on a set of requirements first. > Please let's forget the implementation until we have collected enough > feedbacks on the needs. > I suggest these items to start the list: > > - query all drivers in static binary or shared library This does require a some sort of special section then, but thats fine > - stripping resiliency easy enough > - human friendly done > - script friendly Can be done easily > - show driver name Thats somewhat orthogonal to this problem, the driver name is codified in the rte_driver struct, we just have to be sure that driver writers fill that out > - list supported device id / name > - list driver options Hadn't thought of that, but its a good idea. > - show driver version if available Can be done. > - show dpdk version This is tricky as its not really codified in any DPDK code, especially for DSO's built independently from the dpdk library > - show kernel dependencies (vfio/uio_pci_generic/etc) Same as above, no real way to know that unless driver writers want to manually call out dependencies. > - room for extra information? > > Please ack or comment items of this list, thanks. >