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 0739A5908 for ; Tue, 3 May 2016 13:57:26 +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 1axYx6-0001TC-It; Tue, 03 May 2016 07:57:22 -0400 Date: Tue, 3 May 2016 07:57:14 -0400 From: Neil Horman To: dev@dpdk.org Cc: David Marchand , Stephen Hemminger , bruce.richardson@intel.com, Panu Matilainen , Thomas Monjalon Message-ID: <20160503115714.GA704@hmsreliant.think-freely.org> References: <1461692391-30093-1-git-send-email-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461692391-30093-1-git-send-email-nhorman@tuxdriver.com> 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: Tue, 03 May 2016 11:57:26 -0000 On Tue, Apr 26, 2016 at 01:39:47PM -0400, Neil Horman wrote: > Hey- > So a few days ago we were reviewing Davids patch series to introduce the > abiilty to dump hardware support from pmd DSO's in a human readable format. > That effort encountered some problems, most notably the fact that stripping a > DSO removed the required information that the proposed tool keyed off, as well > as the need to dead reckon offsets between symbols that may not be constant > (dependent on architecture). > > I was going to start looking into the possibility of creating a modinfo > section in a simmilar fashion to what kernel modules do in linux or BSD. I > decided to propose this solution instead though, because the kernel style > solution requires a significant amount of infrastructure that I think we can > maybe avoid maintaining, if we accept some minor caviats > > To do this We emit a set of well known marker symbols for each DSO that an > external application can search for (in this case I called them > this_pmd_driver, where n is a counter macro). These marker symbols are > n is a counter macro). These marker symbols are exported by PMDs for > external access. External tools can then access these symbols via the > dlopen/dlsym api (or via elfutils libraries) > > The symbols above alias the rte_driver struct for each PMD, and the external > application can then interrogate the registered driver information. > > I also add a pointer to the pci id table struct for each PMD so that we can > export hardware support. > > 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. > > 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. > > But regardless, I thought I would propose this to see what you all thought of > it. > > FWIW, heres sample output of the pmdinfo tool from this series probing the > librte_pmd_ena.so module: > > [nhorman@hmsreliant dpdk]$ ./build/app/pmdinfo > ~/git/dpdk/build/lib/librte_pmd_ena.so > PMD 0 Information: > Driver Name: ena_driver > Driver Type: PCI > |====================PCI Table========================| > | VENDOR ID | DEVICE ID | SUBVENDOR ID | SUBDEVICE ID | > |-----------------------------------------------------| > | 1d0f| ec20| ffff| ffff| > | 1d0f| ec21| ffff| ffff| > |-----------------------------------------------------| > > > > Ping, thoughts here? Neil