[dpdk-dev] Importing DATA into the application

[Thomas Monjalon]

08/12/2020 08:03, Narcisa Ana Maria Vasile:
> Hi,
> 
> While using the DPDK libs as DLLs, I've ran into some access violation errors. I believe they are caused by some incorrect imports.
> In Windows, accessing an imported variable is done either by using __declspec(dllimport), or by using an extra level of indirection[1].

Why coding on Windows is so complex?


> Some examples of variables in DPDK that are not declared correctly:
> rte_cycles.h: extern void (*rte_delay_us)(unsigned int us);
> rte_mempool.h: extern struct rte_mempool_ops_table rte_mempool_ops_table;
> rte_lcore.h: RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); (Which expands to extern __thread unsigned per_lcore__lcore_id)
> 
> To fix this, we need to add the __declspec(dllimport) keyword to the declarations of these symbols. Also, we need to consider that the symbols can be used both internally(in the same module) and externally (imported by other modules).
> We can define a macro that will tell if the symbol is used internally or is imported by a different DLL. Example:
> 
> #ifdef RTE_INTERNAL
> extern void (*rte_delay_us)(unsigned int us);
> #else
> __declspec(dllimport) void (*rte_delay_us)(unsigned int us);
> #endif
> 
> We can then hide the Windows-specific keywords under a new macro, such as:
> #define RTE_IMPORT __declspec(dllimport)
> 
> However, there are a few issues to consider:
> * We cannot add __declspec(dllimport)  when declaring per_lcore__lcore_id for example. We cannot have both __thread and __declspec(dllimport)  (can't import thread local variables).

We cannot export a TLS variable? It looks to be a serious issue.


> Have you discussed/run into these issues before? Let me know what you think.

Curiously it has never been discussed in 2 years of DPDK porting to Windows.
Thanks for raising.