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.
> [...]
