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

["Morten Brørup" <mb@smartsharesystems.com>]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tom Barbette
> Sent: Wednesday, March 31, 2021 10:53 AM
> 
> 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
> 

If we are moving away from Compile Time parameters, I certainly prefer Tom's suggestion of Link Time parameters, rather than Run Time parameters.

This might also provide a middle ground for optimizations where Compile Time parameters are considered unacceptable by the DPDK community. I'm thinking about something along the lines of the "constant size" rte_event array presented at the 2020 Userspace Summit by Harry (https://static.sched.com/hosted_files/dpdkuserspace2020/d3/dpdk_userspace_20_api_performance_hvh.pdf). Taking this thinking even further out, a Link Time parameter could perhaps replace the nb_pkts parameter in on optimized rte_eth_rx_burst() function.


Med venlig hilsen / kind regards
- Morten Brørup