> -----Original Message----- > From: Ananyev, Konstantin > Sent: Friday, January 22, 2016 11:05 AM > To: Panu Matilainen; Andralojc, WojciechX > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel > Architecture Model Specific Registers (MSR)... > > > -----Original Message----- > > From: Panu Matilainen [mailto:pmatilai at redhat.com] > > Sent: Friday, January 22, 2016 10:06 AM > > To: Ananyev, Konstantin; Andralojc, WojciechX > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel > Architecture Model Specific Registers (MSR)... > > > > On 01/21/2016 12:51 PM, Ananyev, Konstantin wrote: > > > Hi Panu, > > > > > >> -----Original Message----- > > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu > > >> Matilainen > > >> Sent: Thursday, January 21, 2016 10:39 AM > > >> To: Andralojc, WojciechX > > >> Cc: dev at dpdk.org > > >> Subject: Re: [dpdk-dev] [PATCH v3] Patch introducing API to read/write > Intel Architecture Model Specific Registers (MSR)... > > >> > > >> On 01/21/2016 10:18 AM, Wojciech Andralojc wrote: > > >>> Patch reworked. > > >>> > > >>> Signed-off-by: Wojciech Andralojc <wojciechx.andralojc at intel.com> > > >>> --- > > >>> lib/librte_eal/common/include/arch/x86/rte_msr.h | 88 > +++++++++++++++++ > > >>> lib/librte_eal/linuxapp/eal/Makefile | 1 + > > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c | 116 > +++++++++++++++++++++++ > > >>> 3 files changed, 205 insertions(+) > > >>> create mode 100644 > lib/librte_eal/common/include/arch/x86/rte_msr.h > > >>> create mode 100644 > > >>> lib/librte_eal/linuxapp/eal/arch/x86/rte_msr.c > > >> > > >> This creates a new arch-specific public API, with rte_msr.h > > >> installed as a public header and implementation in the library (as > > >> opposed to inline), and so the new functions would have to be added > > >> to rte_eal_version.map. > > >> > > >> However that is a bit of a problem since it only exists on IA > > >> architectures, so it'd mean dummy entries in the version map for > > >> all other architectures. All the other arch-specific APIs are > > >> inline code so this is the first of its kind. > > > > > > My thought was: > > > 1. implementation is linux specific (as I know not supposed to work under > freebsd). > > > 2. they are not supposed to be used at run-time cide-path, so no need to > > > be > inlined. > > > > Speed is not the only interesting attribute of inlining, inlined code > > also effectively escapes the library ABI so it does not need > > versioning / exporting. > > > > > 3. As I understand we plan to have a library that will use these > > > functions > anyway. > > > > Is this library going to be a generic or specific to Intel CPUs? > > As I understand - yes. > It supposed to utilise new Intel chips CAT abilities. > Wojciech, please correct me if I missed something here.
Konstantin, yes, you are right, CAT enabling lib is Intel CPUs specific. > > > Also, if there are no other uses for the MSR API at the moment, > > perhaps the best place for this code would be within that library anyway? > > Sounds good to me. OK, sounds good. Thank you both for your input. > > Konstantin > > > > > > About dummy entries in the .map file: if we'll create a 'weak' > > > generic implementation, that would just return an error - would it solve > > > the > issue? > > > > Sure it'd solve the issue of dummy entries in .map but people seemed > > opposed to having a highly arch-specific API exposed to all architectures. > > > > - Panu - > > Wojciech Andralojc
