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 Honnappa
> Nagarahalli
> Sent: Wednesday, April 7, 2021 2:48 AM
> 
> <snip>
> >
> > > 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.
> 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.

Yes!

And "if (...)" is more flexible than #ifdef/#if because it allows the expression to be mixed with non-constants.

Then perhaps Bruce's script to automatically make C constants out of #defines was not so silly anyway. :-)

> 
> >
> > 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_usersp
> ac
> > 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.
> >

Optimally, I would like to see e.g. the RX burst size being so constant that the PMD's RX function knows it and can use vector functions and possibly loop unrolling, without having to implement a pre-check on nb_pkts and a trailing non-vector loop for receiving any remaining odd nb_pkts. All the DPDK examples use #define MAX_PKT_BURST 32 or similar, and I assume most DPDK applications do too.

I do not trust the compiler to be clever enough to realize that the PMD's RX function is always called with a specific nb_pkts and optimize all this cruft away at compile time (or at link time), unless it is a #define or a compile time constant.

> >
> > Med venlig hilsen / kind regards
> > - Morten Brørup
> >
> >