From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: driver initialization in DPDK 2.0 built into a shared library. Date: Thu, 16 Jul 2015 14:00:49 +0100 Message-ID: <55A7AB01.1030208@linaro.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: "Polevoy, Igor" , "dev@dpdk.org" Return-path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 24C7E5A66 for ; Thu, 16 Jul 2015 15:00:51 +0200 (CEST) Received: by widjy10 with SMTP id jy10so15095219wid.1 for ; Thu, 16 Jul 2015 06:00:51 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 14/07/15 19:21, Polevoy, Igor wrote: > Hi, > We are developing an application that uses DPDK PMD functionality . > We are using a linux shared library which contains the network packets processing code and it is statically linked with all the necessary DPDK libs. > The .so is loaded by the main program. > For the DPDK compilation we have added the -fPIC to the GCC options. > > While it all worked fine with DPDK 1.6 where we had the rte_pmd_init_all method, in the 2.0 version the > drivers registration methods (PMD_REGISTER_DRIVER) are not called when the shared library is loaded. > > Although, I can go along the lines of the rte_pmd_init all and manually call the driver registration, I'm concerned > that DPDK has other drivers initialization calls, and I don't actually know which are needed or could be needed and when. > > Do you have any advice on that? What is the best way to resolve this issue? > > Thank you > Igor. > I've seen a similar problem, but in a different setup. My app (OVS) links to ODP-DPDK statically, which then links to DPDK code statically. I found that the devinitfn_* functions are not called because OVS doesn't call directly into the DPDK library, only into ODP-DPDK. The workaround for me was to refer to those functions in the ODP-DPDK code: #define PMD_EXT(drv) extern void devinitfn_##drv(void); PMD_EXT(bond_drv) PMD_EXT(em_pmd_drv) ... But there might be better solutions than that. This one is fragile, if you update DPDK you have to remember adding these references for new PMDs. Zoli