Re: [dpdk-dev] RFC enabling dll/dso for dpdk on windows

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

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