[dpdk-dev] Minutes of Technical Board Meeting, 2021-03-10
Tom Barbette
barbette at kth.se
Wed Mar 31 10:52:58 CEST 2021
Le 31-03-21 à 02:44, Honnappa Nagarahalli a écrit :
> - Ability to tune the values of #defines
> * Few prominent points discussed
> - This will result in #ifdefs in the code (for ex: in testpmd)
> - One option is for all the PMDs to document their configurable #defines in PMD specific header files. Having these distributed is much easier to search.
> - Can some of the existing #defines be converted to runtime configurations? For ex: RTE_MAX_LCORE? This might impact ABI.
> * Bruce to think about converting the doc to a blog or an email on the mailing list. But soliciting feedback is most important.
One alternative path worth looking at is to encourage the use of LTO,
and modify APIs so the configuration can be provided at linking time,
and propagated by the compiler.
E.g. one can define rte_max_lcore as a weak constant symbol, equal to
128. At linking time the user may provide a rte_max_lcore that is more
tailored, and still, dynamic arrays[rte_max_lcore] will be allocatable
on the .bss section, avoiding an indirection. The compiler will be able
to optimize loops etc which is impossible with pure runtime configuration.
In packetmill.io we actually pushed this to the next level where the
driver can completely change its behavior without recompiling DPDK
itself and spawning ifdefs everywhere.
However the price is the slowiness of LTO...
My 2 cents.
Tom
More information about the dev
mailing list