>-----Original Message----- >From: Morten Brørup <m...@smartsharesystems.com> >Sent: Friday, January 20, 2023 10:47 AM >To: Tomasz Duszynski <tduszyn...@marvell.com>; dev@dpdk.org; Thomas Monjalon ><tho...@monjalon.net> >Cc: Jerin Jacob Kollanukkaran <jer...@marvell.com>; ruifeng.w...@arm.com; >mattias.ronnb...@ericsson.com; zhou...@loongson.cn; bruce.richard...@intel.com; >roret...@linux.microsoft.com >Subject: [EXT] RE: [PATCH v6 1/4] lib: add generic support for reading PMU >events > >External Email > >---------------------------------------------------------------------- >> From: Tomasz Duszynski [mailto:tduszyn...@marvell.com] >> Sent: Friday, 20 January 2023 00.39 >> >> Add support for programming PMU counters and reading their values in >> runtime bypassing kernel completely. >> >> This is especially useful in cases where CPU cores are isolated >> (nohz_full) i.e run dedicated tasks. In such cases one cannot use >> standard perf utility without sacrificing latency and performance. >> >> Signed-off-by: Tomasz Duszynski <tduszyn...@marvell.com> >> --- > >If you insist on passing lcore_id around as a function parameter, the function >description must >mention that the lcore_id parameter must be set to rte_lcore_id() for the >functions where this is a >requirement, including all functions that use those functions. >
Not sure why are you insisting so much on removing that rte_lcore_id(). Yes that macro evaluates to integer but if you don't think about internals this resembles a function call. Then natural pattern is to call it once and reuse results if possible. Passing lcore_id around implies that calls are per l-core, why would that confuse anyone reading that code? Besides, all functions taking it are internal stuff hence you cannot call it elsewhere. >Alternatively, follow my previous suggestion: Omit the lcore_id function >parameter, and use >rte_lcore_id() instead. >
