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 E1EF3A0C46; Thu, 8 Jul 2021 22:49:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D9144014E; Thu, 8 Jul 2021 22:49:56 +0200 (CEST) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by mails.dpdk.org (Postfix) with ESMTP id 68BC84003E for ; Thu, 8 Jul 2021 22:49:55 +0200 (CEST) Received: by mail-lf1-f48.google.com with SMTP id c28so18293957lfp.11 for ; Thu, 08 Jul 2021 13:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=O+2xelQiQ0A4CyyTMI1aN4+EhVyNttjNYDOsOii8mMY=; b=bjISvH6al1btrhQlRFfWNs+3ebZrie7HIMu79k8unJfxbyZW3V7M8FG85LA+W/nJio 3yRKeMsWbplKIVFRVbWbnpomrpMeRfU/rXLvM6+hNqhJOJStZRjI92qtCG5YJ+zRPgUY ZJhEVlVteIBLYLmy1vcWETdY15wOgn1LmjT4eSWq7P3/sw7QqN+J7txLsmGxDef5q3dV cD5xP0xeVcWh9+wRnxNPKx1lcs8E8f1DfleXzLeRXNNY+/xzb6DHesgsT8NOQOsF1I4P gWtIFAwqXKRThU1LX/Js68nW4dp+pt+X9zeAmNueKmaw+VWWZY3G28rl3O0vhT1JZUat XkVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=O+2xelQiQ0A4CyyTMI1aN4+EhVyNttjNYDOsOii8mMY=; b=I8gva0elg8JmNs1tBc8/ZXxk98Z6gsOPA0tjhsGeGUKs/dJpSK67CsOsPaKCgoPIil 9OBwA/JQuB4uI5hsJt5GQM4nOGwvS5UrXsRuJvQfCV0n0vIKc6VORMhNtSiyVInuSiUd 9Lx+0TrdTBIj02yZzxTcrNwSU59xKPSiB66f0lReze5LegAw5qzKj7M5DvR0sKktnp67 PjYySND6lIMPEnzG1F/l8iLkYF78r6zYvsPS+eYhA2EAusahTyy+JFQl3/0rUSvTfwHp GsFuFsiPVY86Rhn/vo2oDTRv+da1QDM+SwfaieKhQPqwZDNAL4HrJo3LallQwDqnYTF2 /r2Q== X-Gm-Message-State: AOAM530v7EGYbzBrBD2BMOs/WUoPdDXTZSOuMOn9Zi6Z6Ll8H7dJ8lyM 0a6dt16UhteYZ59X0B3ofo8= X-Google-Smtp-Source: ABdhPJzOfF/5YA1MDLKs+Wzo+V3VVXwCKHy2LAK4EGNpm83oeM22XHZ1R5DoIv05IFfJUusSxZtxFg== X-Received: by 2002:a19:4888:: with SMTP id v130mr18915517lfa.68.1625777394840; Thu, 08 Jul 2021 13:49:54 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id f9sm340692ljf.73.2021.07.08.13.49.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jul 2021 13:49:54 -0700 (PDT) Date: Thu, 8 Jul 2021 23:49:53 +0300 From: Dmitry Kozlyuk To: Tyler Retzlaff Cc: dev@dpdk.org, thomas@monjalon.net Message-ID: <20210708234953.67906871@sovereign> In-Reply-To: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" Hi Tyler, 2021-07-08 12:21 (UTC-0700), Tyler Retzlaff: > 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] When will the new loader be available? Will it be ported to Server 2019? Will this functionality require compiler support (you mention that accessing such variables will be "non-trivial")? > (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] Does it affect ABI? It is also a huge code change, although a mechanical one. Is it required? All exported symbols are listed in .map/def, after all. > 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. Either you mean a macro to switch __rte_export between dllimport/dllexport or I don't understand this point. BTW, what will __rte_export be for static build? > > 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' When rte_thread_key*() family of functions was introduced as rte_tls_*(), Jerin objected that there's a confusion with Transport Layer Security. How about RTE_THREAD_VAR, etc? > __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. Is it necessary, i.e. can' RTE_DECLARE/DEFINE_TLS compose with other attributes, like __rte_experimental and __rte_deprecated? > * 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. > [...]