[dpdk-dev] Importing DATA into the application

Narcisa Ana Maria Vasile Narcisa.Vasile at microsoft.com
Tue Dec 8 08:03:05 CET 2020


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


More information about the dev mailing list