[dpdk-dev] Importing DATA into the application

[dpdk-dev] Importing DATA into the application

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

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).

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

Thanks,
Naty

[1] https://docs.microsoft.com/en-us/cpp/build/importing-using-def-files?view=msvc-160

Re: [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.

Re: [dpdk-dev] Importing DATA into the application

[Dmitry Kozlyuk]

On Tue, 08 Dec 2020 08:47:15 +0100, Thomas Monjalon wrote:
> 08/12/2020 08:03, Narcisa Ana Maria Vasile:
[...]
> > 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.

Oh, it has been discussed. I've even made a demo about TLS variables in DLLs
with GCC, which supports them, albeit with a penalty, and Clang, which
doesn't support them. At the time, we agreed that having static linking would
be enough as a first step, now we're past it.