Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-03-10

[Tom Barbette <barbette@kth.se>]

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