<snip> > > > From: dev [mailto:dev-boun...@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. I think compile time constants are fine if they are not used in #ifdef. For ex: if they are used in 'if (...)', it will help eliminate code and branches.
> > 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_userspac > e_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 > >
