From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id D70F42BAF for ; Wed, 4 May 2016 10:24:37 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id g17so79582993wme.1 for ; Wed, 04 May 2016 01:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/OE7PxDae9fX5jDpuwYuKsoZiR3+pGgT0lE0eFhH6jM=; b=1yFtgY5dNWesACo9V8MCiJmUCF2uaRh4q5ZEJh0QEP9vIPgvdrAvaxv8PB2h7TvafS JqrazUgjJL7RNZOirv7m73gVi8t2EVBiAnBd3PregcuVkmdCA78Ui6M4zCj6iaU8Mgif Q48/1fbJwjWs//kNrTHLZZmIbOTq0c88arS9+aS5To83foK3st6ZGBK27F9WF/vPmKZm qWsb3ZkGUH5LN8SEzlWeR1rMUYhW9mHNsT+mpxRaC7euHZ9NBbGy+lZoHQB/mOAv17b9 abgP+hDHKm7v5JfEOqi1DLSE6m+wrVo8IOMFe2cgQghYONTwlQmQKXlpI4I0ZNJSA3DR GjXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/OE7PxDae9fX5jDpuwYuKsoZiR3+pGgT0lE0eFhH6jM=; b=NE7sqhKjjzg50yi9U9W/OVCP3QRxLv9MhcyQD+YdkvBydn3arm+IEVV5GXofNVtWZj U6I6gF/+o+MImCzx3lRbRgWeUedKvDozjyFEhpG48gEhFlGVhk++YM6IiZBC1ZKF26fc n21SqToOJd0Covb3an4eygM4nMBa6zLQQqydIJKsG/0XfJlxNfC/9ATsODSPHeOBc3rd Xm5Oml0WXOXjqVbO93YSut1gZmh42+TOLtnH6yI2LqaMQcbZeD8jRNtVMidVNSRCwKXh Dmm1ixDYnQdGGoWIIBK6vDZJcSci3s3GRdH/Ncu+X6c5/FL0eW4ItP+e4jsXoKWTTTOY lHSA== X-Gm-Message-State: AOPr4FVJENVWG8sHD10d91kxN5YgnkLcKNf1ljpEjP9wPv3JnW7GFi5usjNhOn8Wc9q9MTTfzf+t0pOAzPOD+6On X-Received: by 10.28.161.131 with SMTP id k125mr5103369wme.53.1462350277673; Wed, 04 May 2016 01:24:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.16.2 with HTTP; Wed, 4 May 2016 01:24:18 -0700 (PDT) In-Reply-To: <20160503115714.GA704@hmsreliant.think-freely.org> References: <1461692391-30093-1-git-send-email-nhorman@tuxdriver.com> <20160503115714.GA704@hmsreliant.think-freely.org> From: David Marchand Date: Wed, 4 May 2016 10:24:18 +0200 Message-ID: To: Neil Horman Cc: "dev@dpdk.org" , Stephen Hemminger , "Richardson, Bruce" , Panu Matilainen , Thomas Monjalon Content-Type: text/plain; charset=UTF-8 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: Wed, 04 May 2016 08:24:38 -0000 On Tue, May 3, 2016 at 1:57 PM, Neil Horman wrote: > 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? - 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. - The name of the tool "pmdinfo" is likely to cause problems, I would say we need to prefix t with dpdk. - How does it behave if we strip the dsos ? - Using __COUNTER__ seeems a bit tricky to me, can't this cause misalignments ? - The tool output format is not script friendly from my pov. -- David Marchand