>-----Original Message----- >From: Morten Brørup <[email protected]> >Sent: Friday, January 20, 2023 10:47 AM >To: Tomasz Duszynski <[email protected]>; [email protected]; Thomas Monjalon ><[email protected]> >Cc: Jerin Jacob Kollanukkaran <[email protected]>; [email protected]; >[email protected]; [email protected]; [email protected]; >[email protected] >Subject: [EXT] RE: [PATCH v6 1/4] lib: add generic support for reading PMU >events > >External Email > >---------------------------------------------------------------------- >> From: Tomasz Duszynski [mailto:[email protected]] >> 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 <[email protected]> >> --- > >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. >
