From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 27706A0548; Fri, 9 Jul 2021 18:09:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FDC1416FB; Fri, 9 Jul 2021 18:09:08 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 8A48C41707 for ; Fri, 9 Jul 2021 18:09:05 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id DA96120B7178; Fri, 9 Jul 2021 09:09:04 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com DA96120B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1625846944; bh=Nn+2hJdD2H3UyLB66eHBViVxJsiu4o38LAk9EUqRb5U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bVKzaJJrQ7L9fuDj88c+a/rD17MpGfDwVm1atvNLE1y07NHMAth0R/3pAXJZWDsW8 UZmePsqF9PiW55ImaP/1g8Xz+jTTGoIrvDdCaE9c0mHaJU5/LlQBhyVWDQmt3HzVsS kVs78jg/PlMrNXDNsOQelZcVdCUHid1627lK1ofg= Date: Fri, 9 Jul 2021 09:09:04 -0700 From: Tyler Retzlaff To: Thomas Monjalon Cc: dev@dpdk.org, dmitry.kozliuk@gmail.com Message-ID: <20210709160904.GC23346@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <1925991.Mh3L70K1Gt@thomas> <20210709001656.GA23346@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <2327932.72rn2HgcyV@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2327932.72rn2HgcyV@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] RFC enabling dll/dso for dpdk on windows X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jul 09, 2021 at 01:34:06PM +0200, Thomas Monjalon wrote: > 09/07/2021 02:16, Tyler Retzlaff: > > On Thu, Jul 08, 2021 at 10:39:13PM +0200, Thomas Monjalon wrote: > > > 08/07/2021 21:21, Tyler Retzlaff: > > > > (2) importing exported data symbols from a dll/dso on windows requires > > > > that the symbol be decorated with dllimport. optionally loading > > > > performance of dll/dso is also further improved by decorating > > > > exported function symbols. [3] > > > > > > > > for (2) we would propose the introduction and use of two macros to > > > > allow decoration of exported data symbols. these macro would be or > > > > similarly named __rte_import and __rte_export. of note > > > > > > That's the same symbol declared in a single place > > > which is exported and imported. > > > So I don't understand the need for 2 macros. > > > > i may be misinterpreting your reply. you're saying there is no need for > > 2 because we use .def files? > > > > strictly speaking when exporting C symbols this is true. so yes, we > > could introduce only __rte_import and not bother with __rte_export. > > > > is that what you meant? > > > > i don't have any objection to just __rte_import alone but it is > > mandatory for data symbols. > > It may be my misunderstanding. > The function is declared only once in the .h > so I don't understand where these 2 macros are used. > okay, i think the question is about mechanically where they are used and i'll limit my answer to data symbols since that's what we need them for. the export is typically used at the point of definition and the import at declaration. so ignoring anything about tls the following example hopefully illustrates. let's start with a module i'll just call it eal.dll it is declaring a data symbol that will be exported and may be referenced internally within eal.dll itself but also externally by other modules outside of eal.dll. // eal.c __rte_export int eal_some_var; // eal.h #ifndef BUILDING_EAL __rte_import #endif extern int eal_some_var; // eal_other.c #define BUILDING_EAL #include eal_some_var = 100; we also have another module app.exe that consumes the variable exported from eal.dll. // app.c #include eal_some_var = 200; as mentioned in my first reply you can get away with not using __rte_export because dpdk also lists the exports in the .map/.def files even for data symbols but it is required for import [1]. the relevant text from the documentation is quoted here. Using __declspec(dllimport) is optional on function declarations, but the compiler produces more efficient code if you use this keyword. However, you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols and objects. Note that the users of your DLL still need to link with an import library. specifically "you must use __declspec(dllimport) for the importing executable to access the DLL's public data symbols" is relevant. the other internal/external conditional compile for BUILDING_EAL is applied to avoid generating the code for the extra layer of indirection mentioned here [2] when using the variable in the same module in which it was defined. 1. https://docs.microsoft.com/en-us/cpp/build/importing-into-an-application-using-declspec-dllimport?view=msvc-160 2. https://docs.microsoft.com/en-us/cpp/build/importing-data-using-declspec-dllimport?view=msvc-160