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

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

(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