From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: dev@dpdk.org, dmitry.kozliuk@gmail.com, thomas@monjalon.net
Subject: [dpdk-dev] RFC enabling dll/dso for dpdk on windows
Date: Thu, 8 Jul 2021 12:21:09 -0700 [thread overview]
Message-ID: <20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
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
next reply other threads:[~2021-07-08 19:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 19:21 Tyler Retzlaff [this message]
2021-07-08 20:39 ` [dpdk-dev] RFC enabling dll/dso for dpdk on windows Thomas Monjalon
2021-07-09 0:16 ` Tyler Retzlaff
2021-07-09 11:34 ` Thomas Monjalon
2021-07-09 16:09 ` Tyler Retzlaff
2021-07-08 20:49 ` Dmitry Kozlyuk
2021-07-09 1:03 ` Tyler Retzlaff
2021-07-16 9:40 ` Dmitry Kozlyuk
2021-07-19 3:45 ` Tyler Retzlaff
2021-07-19 9:12 ` Dmitry Kozlyuk
2021-07-19 16:51 ` Tyler Retzlaff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210708192109.GA13966@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=roretzla@linux.microsoft.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.