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

From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
	"Tom Barbette" <barbette@kth.se>, "dev@dpdk.org" <dev@dpdk.org>
Cc: nd <nd@arm.com>, Alireza Farshin <farshin@kth.se>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] Minutes of Technical Board Meeting, 2021-03-10
Date: Wed, 7 Apr 2021 00:47:40 +0000	[thread overview]
Message-ID: <DBAPR08MB5814E1DFA1AA33229B10A6FE98759@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C616BF@smartserver.smartshare.dk>

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

> 
> 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
> 
>