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 6CC17A0C48; Thu, 8 Jul 2021 21:21:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF91E4014E; Thu, 8 Jul 2021 21:21:11 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id CC8694003E for ; Thu, 8 Jul 2021 21:21:09 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 152B620B7178; Thu, 8 Jul 2021 12:21:09 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 152B620B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1625772069; bh=Q/OUcj8MA8G4Ot0Pg+wl1/jDVvx5xD+1WgPo0ur2oaQ=; h=Date:From:To:Subject:From; b=GgD4ZinedBL6fax1LTOWFY0ZQ17NvUUlHxrrznIjWkR3SrOMGarsNhYR/xLTFu1QN +5dkOFW0W1ifl3znBzKIg7nujvvJEWOs9MXxypmav1XNTet/NG8dAcGLArbZkl3VBI AKpZqjFnlAQUm+ehoiYzHqOf5Kt5MhPYI4+eMWaY= Date: Thu, 8 Jul 2021 12:21:09 -0700 From: Tyler Retzlaff To: dev@dpdk.org, dmitry.kozliuk@gmail.com, thomas@monjalon.net Message-ID: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [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" hi folks, we would like to submit a a patch series that makes dll/dso for dpdk work on windows. there are two differences in the windows platform that would need to be address through enhancements to dpdk. (1) windows dynamic objects don't export sufficient information for tls variables and the windows loader and runtime would need to be enhanced in order to perform runtime linking. [1][2] (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 (1) a novel approach is proposed where a new set of per_lcore macros are introduced and used to replace existing macros with some adjustment to declaration/definition usage is made. of note * on linux the new macros would expand compatibly to maintain abi of existing exported tls variables. since windows dynamic linking has never worked there is no compatibility concern for existing windows binaries. * the existing macros would be retained for api compatibility potentially with the intent of deprecating them at a later time. * new macros would be "internal" to dpdk they should not be available to applications as a part of the stable api. 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 * on linux the macros would expand empty but optionally in the future__rte_export could be enhanced to expand to __attribute__((visibility("default"))) enabling the use of gcc -fvisibility=hidden in dpdk to improve dso load times. [4][5] * on windows the macros would trivially expand to __declspec(dllimport) and __declspec(dllexport) * library meson.build files would need to define a preprocessor knob to control decoration internal/external to libraries exporting data symbols to ensure optimal code generation for accesses. the following is the base list of proposed macro additions for the new per_lcore macros a new header is proposed named `rte_tls.h' __rte_export __rte_import have already been explained in (2) __rte_thread_local is trivially expanded to __thread or _Thread_local or __declspec(thread) as appropriate. RTE_DEFINE_TLS(vartype, varname, value) RTE_DEFINE_TLS_EXPORT(vartype, varname, value) RTE_DECLARE_TLS(vartype, varname) RTE_DECLARE_TLS_IMPORT(vartype, varname) are roughly equivalent to RTE_DEFINE_PER_LCORE and RTE_DECLARE_PER_LCORE where the difference in the new macros are. * separate macros for exported vs non-exported variables. * DEFINE macros require initialization value as a parameter instead of the assignment usage. `RTE_DEFINE_PER_LCORE(t, n) = x;' there was no reasonable way to expand the windows variant of the macro to maintain assignment so it was parameterized to allow flexibility. RTE_TLS(varname) is the equivalent of RTE_PER_LCORE to allow r/w access to the variable on linux the expansion is the same for windows it is non-trivial. we look forward to feedback on this proposal, once we have initial feedback the series will be submitted where further review can take place. thanks 1. https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2492?view=msvc-160 2. https://docs.microsoft.com/en-us/windows/win32/debug/pe-format 3. https://docs.microsoft.com/en-us/cpp/build/importing-into-an-application-using-declspec-dllimport?view=msvc-160 4. https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Function-Attributes.html 5. https://gcc.gnu.org/wiki/Visibility