[dpdk-dev] [PATCH v3] Patch introducing API to read/write Intel Architecture Model Specific Registers (MSR)...

[Ananyev, Konstantin]

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.
3. As I understand we plan to  have a library that will use these functions anyway.

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? 

Konstantin

> 
> Jerin Jacob suggested [1] adding these as internal (inline) functions
> which to me looks like a more sensible approach, arch-specific APIs tend
> to be problematic.
> 
> [1] http://dpdk.org/ml/archives/dev/2016-January/031095.html
> 
> 	- Panu -