RE: [PATCH v3 1/3] eal: add lcore poll busyness telemetry

From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>
Cc: "Kevin Laatz" <kevin.laatz@intel.com>,
	"Jerin Jacob" <jerinjacobk@gmail.com>,
	"Anatoly Burakov" <anatoly.burakov@intel.com>,
	"dpdk-dev" <dev@dpdk.org>, "Conor Walsh" <conor.walsh@intel.com>,
	"David Hunt" <david.hunt@intel.com>,
	"Nicolas Chautru" <nicolas.chautru@intel.com>,
	"Fan Zhang" <roy.fan.zhang@intel.com>,
	"Ashish Gupta" <ashish.gupta@marvell.com>,
	"Akhil Goyal" <gakhil@marvell.com>,
	"Chengwen Feng" <fengchengwen@huawei.com>,
	"Ray Kinsella" <mdr@ashroe.eu>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Ferruh Yigit" <ferruh.yigit@xilinx.com>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
	"Jerin Jacob" <jerinj@marvell.com>,
	"Sachin Saxena" <sachin.saxena@oss.nxp.com>,
	"Hemant Agrawal" <hemant.agrawal@nxp.com>,
	"Ori Kam" <orika@nvidia.com>,
	"Honnappa Nagarahalli" <honnappa.nagarahalli@arm.com>,
	"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>
Subject: RE: [PATCH v3 1/3] eal: add lcore poll busyness telemetry
Date: Mon, 29 Aug 2022 13:22:37 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D872CA@smartserver.smartshare.dk> (raw)
In-Reply-To: <YwyXyFZVXhuK1lua@bricha3-MOBL.ger.corp.intel.com>

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 29 August 2022 12.41
> 
> On Fri, Aug 26, 2022 at 05:46:48PM +0200, Morten Brørup wrote:
> >
> > Also, there's a new discussion about EAL bloat [1]. Perhaps I'm
> stretching it here, but it would be nice if your library was made a
> separate library, instead of part of the EAL library. (Since this kind
> of feature is not new to the EAL, I will categorize this suggestion as
> "nice to have", not "must have".)
> >
> > [1] http://inbox.dpdk.org/dev/2594603.Isy0gbHreE@thomas/T/
> >
> 
> I was actually discussing this with Kevin and Dave H. on Friay, and
> trying
> to make this a separate library is indeed a big stretch. :-)
> 
> From that discussion, the key point/gap is that we are really missing a
> clean way of providing undefs or macro fallbacks for when a library is
> just
> not present. For example, if this was a separate library we would gain
> a
> number of advantages e.g. no need for separate enable/disable flag, but
> the
> big disadvantage is that every header include for it, and every
> reference
> to the macros used in that header need to be surrounded by big ugly
> ifdefs.

I agree that we don't want everything surrounded by big ugly ifdefs.

I think solving this should be the responsibility of a library itself, not of the application or other libraries.

E.g. like the mbuf library's use of RTE_LIBRTE_MBUF_DEBUG.

Additionally, a no-op variant of the library could be required, to be compiled in when the library is disabled at build time.

> 
> For now, adding this into EAL is the far more practical approach, since
> it
> means that even if support for the feature is disabled at build time
> the
> header is still available to provide the appropriate no-op macros.

I think you already discovered the key to solving this problem, but perhaps didn't even notice it yourselves:

It must be possible to omit the *feature* at build time - not necessarily the *library*.