[API-NEXT,PATCHv3,1/3] api: dev: add device apis for numa support

Message ID 1477344567-2561-1-git-send-email-bill.fischofer@linaro.org
State New
Headers show

Commit Message

Bill Fischofer Oct. 24, 2016, 9:29 p.m.
Add the odp_dev_id() API used for NUMA support

Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

---
Changes for v3:
- Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

Changes for v2:
- Incorporate changes suggested by Petri

 include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 include/odp/api/spec/dev.h

-- 
2.7.4

Comments

Bill Fischofer Dec. 6, 2016, 3:43 a.m. | #1
Ping. v3 of this patch is still awaiting review.

On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer
<bill.fischofer@linaro.org> wrote:
> Add the odp_dev_id() API used for NUMA support

>

> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

> ---

> Changes for v3:

> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>

> Changes for v2:

> - Incorporate changes suggested by Petri

>

>  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++

>  1 file changed, 89 insertions(+)

>  create mode 100644 include/odp/api/spec/dev.h

>

> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> new file mode 100644

> index 0000000..76d861a

> --- /dev/null

> +++ b/include/odp/api/spec/dev.h

> @@ -0,0 +1,89 @@

> +/* Copyright (c) 2016, Linaro Limited

> + * All rights reserved.

> + *

> + * SPDX-License-Identifier:     BSD-3-Clause

> + */

> +

> +/**

> + * @file

> + *

> + * ODP device

> + */

> +

> +#ifndef ODP_API_DEV_H_

> +#define ODP_API_DEV_H_

> +#include <odp/visibility_begin.h>

> +

> +#ifdef __cplusplus

> +extern "C" {

> +#endif

> +

> +#include <odp/api/std_types.h>

> +

> +/** @defgroup odp_dev ODP DEVICE

> + *  Operations on devices

> + *  @{

> + */

> +

> +/**

> + * @typedef odp_dev_t

> + * ODP Device

> + */

> +

> +/**

> + * @def ODP_DEV_NAME_LEN

> + * Maximum device name length in chars

> + */

> +

> +/**

> + * @def ODP_DEV_DEFAULT

> + * Default device

> + */

> +

> +/**

> + * @def ODP_DEV_INVALID

> + * Invalid device

> + */

> +

> +/**

> + * Get Device ID by Name

> + *

> + * Get an implementation-defined device identifier from a device name. Device

> + * names are supplied as parameter info (command line, file, etc.) to the

> + * application. This routine translates this symbolic name into an internal

> + * identifier that can be used to define a device connection hierarchy for

> + * NUMA or other purposes.

> + *

> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder

> + * wherever a device id is required.

> + *

> + * @param name Name of the device

> + *

> + * @return Device ID

> + * @retval ODP_DEV_INVALID Device is unknown

> + */

> +odp_dev_t odp_dev_id(const char *name);

> +

> +/**

> + * Get printable value for an odp_dev_t

> + *

> + * @param hdl  odp_dev_t handle to be printed

> + * @return     uint64_t value that can be used to print/display this

> + *             handle

> + *

> + * @note This routine is intended to be used for diagnostic purposes

> + * to enable applications to generate a printable value that represents

> + * an odp_dev_t handle.

> + */

> +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> +

> +/**

> + * @}

> + */

> +

> +#ifdef __cplusplus

> +}

> +#endif

> +

> +#include <odp/visibility_end.h>

> +#endif

> --

> 2.7.4

>
Francois Ozog Dec. 6, 2016, 11:03 a.m. | #2
Hi Bill,

could you clarify if this "device" is related to devicetree as defined by
Linaro (https://github.com/devicetree-org/devicetree-specification) or the
devices that are in the scope of Christophe Millard, or some other device
concept ?

FF



On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>
wrote:

> Ping. v3 of this patch is still awaiting review.

>

> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

> <bill.fischofer@linaro.org> wrote:

> > Add the odp_dev_id() API used for NUMA support

> >

> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

> > ---

> > Changes for v3:

> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

> >

> > Changes for v2:

> > - Incorporate changes suggested by Petri

> >

> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

> ++++++++++++++++

> >  1 file changed, 89 insertions(+)

> >  create mode 100644 include/odp/api/spec/dev.h

> >

> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> > new file mode 100644

> > index 0000000..76d861a

> > --- /dev/null

> > +++ b/include/odp/api/spec/dev.h

> > @@ -0,0 +1,89 @@

> > +/* Copyright (c) 2016, Linaro Limited

> > + * All rights reserved.

> > + *

> > + * SPDX-License-Identifier:     BSD-3-Clause

> > + */

> > +

> > +/**

> > + * @file

> > + *

> > + * ODP device

> > + */

> > +

> > +#ifndef ODP_API_DEV_H_

> > +#define ODP_API_DEV_H_

> > +#include <odp/visibility_begin.h>

> > +

> > +#ifdef __cplusplus

> > +extern "C" {

> > +#endif

> > +

> > +#include <odp/api/std_types.h>

> > +

> > +/** @defgroup odp_dev ODP DEVICE

> > + *  Operations on devices

> > + *  @{

> > + */

> > +

> > +/**

> > + * @typedef odp_dev_t

> > + * ODP Device

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_NAME_LEN

> > + * Maximum device name length in chars

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_DEFAULT

> > + * Default device

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_INVALID

> > + * Invalid device

> > + */

> > +

> > +/**

> > + * Get Device ID by Name

> > + *

> > + * Get an implementation-defined device identifier from a device name.

> Device

> > + * names are supplied as parameter info (command line, file, etc.) to

> the

> > + * application. This routine translates this symbolic name into an

> internal

> > + * identifier that can be used to define a device connection hierarchy

> for

> > + * NUMA or other purposes.

> > + *

> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

> placeholder

> > + * wherever a device id is required.

> > + *

> > + * @param name Name of the device

> > + *

> > + * @return Device ID

> > + * @retval ODP_DEV_INVALID Device is unknown

> > + */

> > +odp_dev_t odp_dev_id(const char *name);

> > +

> > +/**

> > + * Get printable value for an odp_dev_t

> > + *

> > + * @param hdl  odp_dev_t handle to be printed

> > + * @return     uint64_t value that can be used to print/display this

> > + *             handle

> > + *

> > + * @note This routine is intended to be used for diagnostic purposes

> > + * to enable applications to generate a printable value that represents

> > + * an odp_dev_t handle.

> > + */

> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> > +

> > +/**

> > + * @}

> > + */

> > +

> > +#ifdef __cplusplus

> > +}

> > +#endif

> > +

> > +#include <odp/visibility_end.h>

> > +#endif

> > --

> > 2.7.4

> >

>




-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Bill Fischofer Dec. 6, 2016, 1:23 p.m. | #3
On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>
wrote:

> Hi Bill,

>

> could you clarify if this "device" is related to devicetree as defined by

> Linaro (https://github.com/devicetree-org/devicetree-specification) or

> the devices that are in the scope of Christophe Millard, or some other

> device concept ?

>


This is the Device ID proposal that Petri suggested at BKK16. It is not
related to devtree or any other specific taxonomy as the idea was to
establish an abstract "device" framework that would support both individual
sockets or multi-SoC environments. In odp-linux these are basically
placeholder functions as we don't have any cross-platform concept of NUMA.
The idea is that each individual platform that does support NUMA should be
able to map their native concepts into this framework to permit
applications to associate an internal odp_dev_t handle with named devices.


>

> FF

>

>

>

> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

>> Ping. v3 of this patch is still awaiting review.

>>

>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>> <bill.fischofer@linaro.org> wrote:

>> > Add the odp_dev_id() API used for NUMA support

>> >

>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>> > ---

>> > Changes for v3:

>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>> >

>> > Changes for v2:

>> > - Incorporate changes suggested by Petri

>> >

>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>> ++++++++++++++++

>> >  1 file changed, 89 insertions(+)

>> >  create mode 100644 include/odp/api/spec/dev.h

>> >

>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>> > new file mode 100644

>> > index 0000000..76d861a

>> > --- /dev/null

>> > +++ b/include/odp/api/spec/dev.h

>> > @@ -0,0 +1,89 @@

>> > +/* Copyright (c) 2016, Linaro Limited

>> > + * All rights reserved.

>> > + *

>> > + * SPDX-License-Identifier:     BSD-3-Clause

>> > + */

>> > +

>> > +/**

>> > + * @file

>> > + *

>> > + * ODP device

>> > + */

>> > +

>> > +#ifndef ODP_API_DEV_H_

>> > +#define ODP_API_DEV_H_

>> > +#include <odp/visibility_begin.h>

>> > +

>> > +#ifdef __cplusplus

>> > +extern "C" {

>> > +#endif

>> > +

>> > +#include <odp/api/std_types.h>

>> > +

>> > +/** @defgroup odp_dev ODP DEVICE

>> > + *  Operations on devices

>> > + *  @{

>> > + */

>> > +

>> > +/**

>> > + * @typedef odp_dev_t

>> > + * ODP Device

>> > + */

>> > +

>> > +/**

>> > + * @def ODP_DEV_NAME_LEN

>> > + * Maximum device name length in chars

>> > + */

>> > +

>> > +/**

>> > + * @def ODP_DEV_DEFAULT

>> > + * Default device

>> > + */

>> > +

>> > +/**

>> > + * @def ODP_DEV_INVALID

>> > + * Invalid device

>> > + */

>> > +

>> > +/**

>> > + * Get Device ID by Name

>> > + *

>> > + * Get an implementation-defined device identifier from a device name.

>> Device

>> > + * names are supplied as parameter info (command line, file, etc.) to

>> the

>> > + * application. This routine translates this symbolic name into an

>> internal

>> > + * identifier that can be used to define a device connection hierarchy

>> for

>> > + * NUMA or other purposes.

>> > + *

>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>> placeholder

>> > + * wherever a device id is required.

>> > + *

>> > + * @param name Name of the device

>> > + *

>> > + * @return Device ID

>> > + * @retval ODP_DEV_INVALID Device is unknown

>> > + */

>> > +odp_dev_t odp_dev_id(const char *name);

>> > +

>> > +/**

>> > + * Get printable value for an odp_dev_t

>> > + *

>> > + * @param hdl  odp_dev_t handle to be printed

>> > + * @return     uint64_t value that can be used to print/display this

>> > + *             handle

>> > + *

>> > + * @note This routine is intended to be used for diagnostic purposes

>> > + * to enable applications to generate a printable value that represents

>> > + * an odp_dev_t handle.

>> > + */

>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>> > +

>> > +/**

>> > + * @}

>> > + */

>> > +

>> > +#ifdef __cplusplus

>> > +}

>> > +#endif

>> > +

>> > +#include <odp/visibility_end.h>

>> > +#endif

>> > --

>> > 2.7.4

>> >

>>

>

>

>

> --

> [image: Linaro] <http://www.linaro.org/>

> François-Frédéric Ozog | *Director Linaro Networking Group*

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>
Bill Fischofer Dec. 6, 2016, 1:24 p.m. | #4
On Tue, Dec 6, 2016 at 7:23 AM, Bill Fischofer <bill.fischofer@linaro.org>
wrote:

>

>

> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

>> Hi Bill,

>>

>> could you clarify if this "device" is related to devicetree as defined by

>> Linaro (https://github.com/devicetree-org/devicetree-specification) or

>> the devices that are in the scope of Christophe Millard, or some other

>> device concept ?

>>

>

> This is the Device ID proposal that Petri suggested at BKK16. It is not

> related to devtree or any other specific taxonomy

>


Typo. This was suggested by Petri as LAS16.


> as the idea was to establish an abstract "device" framework that would

> support both individual sockets or multi-SoC environments. In odp-linux

> these are basically placeholder functions as we don't have any

> cross-platform concept of NUMA. The idea is that each individual platform

> that does support NUMA should be able to map their native concepts into

> this framework to permit applications to associate an internal odp_dev_t

> handle with named devices.

>

>

>>

>> FF

>>

>>

>>

>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

>> wrote:

>>

>>> Ping. v3 of this patch is still awaiting review.

>>>

>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>> <bill.fischofer@linaro.org> wrote:

>>> > Add the odp_dev_id() API used for NUMA support

>>> >

>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>> > ---

>>> > Changes for v3:

>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>> >

>>> > Changes for v2:

>>> > - Incorporate changes suggested by Petri

>>> >

>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>> ++++++++++++++++

>>> >  1 file changed, 89 insertions(+)

>>> >  create mode 100644 include/odp/api/spec/dev.h

>>> >

>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>> > new file mode 100644

>>> > index 0000000..76d861a

>>> > --- /dev/null

>>> > +++ b/include/odp/api/spec/dev.h

>>> > @@ -0,0 +1,89 @@

>>> > +/* Copyright (c) 2016, Linaro Limited

>>> > + * All rights reserved.

>>> > + *

>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>> > + */

>>> > +

>>> > +/**

>>> > + * @file

>>> > + *

>>> > + * ODP device

>>> > + */

>>> > +

>>> > +#ifndef ODP_API_DEV_H_

>>> > +#define ODP_API_DEV_H_

>>> > +#include <odp/visibility_begin.h>

>>> > +

>>> > +#ifdef __cplusplus

>>> > +extern "C" {

>>> > +#endif

>>> > +

>>> > +#include <odp/api/std_types.h>

>>> > +

>>> > +/** @defgroup odp_dev ODP DEVICE

>>> > + *  Operations on devices

>>> > + *  @{

>>> > + */

>>> > +

>>> > +/**

>>> > + * @typedef odp_dev_t

>>> > + * ODP Device

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_NAME_LEN

>>> > + * Maximum device name length in chars

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_DEFAULT

>>> > + * Default device

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_INVALID

>>> > + * Invalid device

>>> > + */

>>> > +

>>> > +/**

>>> > + * Get Device ID by Name

>>> > + *

>>> > + * Get an implementation-defined device identifier from a device

>>> name. Device

>>> > + * names are supplied as parameter info (command line, file, etc.) to

>>> the

>>> > + * application. This routine translates this symbolic name into an

>>> internal

>>> > + * identifier that can be used to define a device connection

>>> hierarchy for

>>> > + * NUMA or other purposes.

>>> > + *

>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>> placeholder

>>> > + * wherever a device id is required.

>>> > + *

>>> > + * @param name Name of the device

>>> > + *

>>> > + * @return Device ID

>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>> > + */

>>> > +odp_dev_t odp_dev_id(const char *name);

>>> > +

>>> > +/**

>>> > + * Get printable value for an odp_dev_t

>>> > + *

>>> > + * @param hdl  odp_dev_t handle to be printed

>>> > + * @return     uint64_t value that can be used to print/display this

>>> > + *             handle

>>> > + *

>>> > + * @note This routine is intended to be used for diagnostic purposes

>>> > + * to enable applications to generate a printable value that

>>> represents

>>> > + * an odp_dev_t handle.

>>> > + */

>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>> > +

>>> > +/**

>>> > + * @}

>>> > + */

>>> > +

>>> > +#ifdef __cplusplus

>>> > +}

>>> > +#endif

>>> > +

>>> > +#include <odp/visibility_end.h>

>>> > +#endif

>>> > --

>>> > 2.7.4

>>> >

>>>

>>

>>

>>

>> --

>> [image: Linaro] <http://www.linaro.org/>

>> François-Frédéric Ozog | *Director Linaro Networking Group*

>> T: +33.67221.6485

>> francois.ozog@linaro.org | Skype: ffozog

>>

>>

>
Francois Ozog Dec. 6, 2016, 2:47 p.m. | #5
Devicetree has been formed by and for SoC vendors to represent what they
have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ
lines, firmware -
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf).....
so it looks like very similar to what Petri is talking about.

ACPI has also a concept of a proximity domains and the relative cost to use
a resource from another domain.

Handling NUMA requires a well thought through approach because it has
implications at many levels in particular for device and driver framework.

Bottom line, regardless if it's value, the introduction of the API seem too
early as I haven't seen the use case that it supports and in particular the
device and drivers framework.

FF






On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>
wrote:

>

>

> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

>> Hi Bill,

>>

>> could you clarify if this "device" is related to devicetree as defined by

>> Linaro (https://github.com/devicetree-org/devicetree-specification) or

>> the devices that are in the scope of Christophe Millard, or some other

>> device concept ?

>>

>

> This is the Device ID proposal that Petri suggested at BKK16. It is not

> related to devtree or any other specific taxonomy as the idea was to

> establish an abstract "device" framework that would support both individual

> sockets or multi-SoC environments. In odp-linux these are basically

> placeholder functions as we don't have any cross-platform concept of NUMA.

> The idea is that each individual platform that does support NUMA should be

> able to map their native concepts into this framework to permit

> applications to associate an internal odp_dev_t handle with named devices.

>

>

>>

>> FF

>>

>>

>>

>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

>> wrote:

>>

>>> Ping. v3 of this patch is still awaiting review.

>>>

>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>> <bill.fischofer@linaro.org> wrote:

>>> > Add the odp_dev_id() API used for NUMA support

>>> >

>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>> > ---

>>> > Changes for v3:

>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>> >

>>> > Changes for v2:

>>> > - Incorporate changes suggested by Petri

>>> >

>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>> ++++++++++++++++

>>> >  1 file changed, 89 insertions(+)

>>> >  create mode 100644 include/odp/api/spec/dev.h

>>> >

>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>> > new file mode 100644

>>> > index 0000000..76d861a

>>> > --- /dev/null

>>> > +++ b/include/odp/api/spec/dev.h

>>> > @@ -0,0 +1,89 @@

>>> > +/* Copyright (c) 2016, Linaro Limited

>>> > + * All rights reserved.

>>> > + *

>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>> > + */

>>> > +

>>> > +/**

>>> > + * @file

>>> > + *

>>> > + * ODP device

>>> > + */

>>> > +

>>> > +#ifndef ODP_API_DEV_H_

>>> > +#define ODP_API_DEV_H_

>>> > +#include <odp/visibility_begin.h>

>>> > +

>>> > +#ifdef __cplusplus

>>> > +extern "C" {

>>> > +#endif

>>> > +

>>> > +#include <odp/api/std_types.h>

>>> > +

>>> > +/** @defgroup odp_dev ODP DEVICE

>>> > + *  Operations on devices

>>> > + *  @{

>>> > + */

>>> > +

>>> > +/**

>>> > + * @typedef odp_dev_t

>>> > + * ODP Device

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_NAME_LEN

>>> > + * Maximum device name length in chars

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_DEFAULT

>>> > + * Default device

>>> > + */

>>> > +

>>> > +/**

>>> > + * @def ODP_DEV_INVALID

>>> > + * Invalid device

>>> > + */

>>> > +

>>> > +/**

>>> > + * Get Device ID by Name

>>> > + *

>>> > + * Get an implementation-defined device identifier from a device

>>> name. Device

>>> > + * names are supplied as parameter info (command line, file, etc.) to

>>> the

>>> > + * application. This routine translates this symbolic name into an

>>> internal

>>> > + * identifier that can be used to define a device connection

>>> hierarchy for

>>> > + * NUMA or other purposes.

>>> > + *

>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>> placeholder

>>> > + * wherever a device id is required.

>>> > + *

>>> > + * @param name Name of the device

>>> > + *

>>> > + * @return Device ID

>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>> > + */

>>> > +odp_dev_t odp_dev_id(const char *name);

>>> > +

>>> > +/**

>>> > + * Get printable value for an odp_dev_t

>>> > + *

>>> > + * @param hdl  odp_dev_t handle to be printed

>>> > + * @return     uint64_t value that can be used to print/display this

>>> > + *             handle

>>> > + *

>>> > + * @note This routine is intended to be used for diagnostic purposes

>>> > + * to enable applications to generate a printable value that

>>> represents

>>> > + * an odp_dev_t handle.

>>> > + */

>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>> > +

>>> > +/**

>>> > + * @}

>>> > + */

>>> > +

>>> > +#ifdef __cplusplus

>>> > +}

>>> > +#endif

>>> > +

>>> > +#include <odp/visibility_end.h>

>>> > +#endif

>>> > --

>>> > 2.7.4

>>> >

>>>

>>

>>

>>

>> --

>> [image: Linaro] <http://www.linaro.org/>

>> François-Frédéric Ozog | *Director Linaro Networking Group*

>> T: +33.67221.6485

>> francois.ozog@linaro.org | Skype: ffozog

>>

>>

>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Bill Fischofer Dec. 6, 2016, 2:59 p.m. | #6
I have no problem deferring this if we want to have one of the SoC vendors
drive a more comprehensive approach based on their capabilities which can
then be generalized. BTW, your link doesn't resolve. Typo somewhere?

On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org>
wrote:

> Devicetree has been formed by and for SoC vendors to represent what they

> have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ

> lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/

> petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so

> it looks like very similar to what Petri is talking about.

>

> ACPI has also a concept of a proximity domains and the relative cost to

> use a resource from another domain.

>

> Handling NUMA requires a well thought through approach because it has

> implications at many levels in particular for device and driver framework.

>

> Bottom line, regardless if it's value, the introduction of the API seem

> too early as I haven't seen the use case that it supports and in particular

> the device and drivers framework.

>

> FF

>

>

>

>

>

>

> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

>>

>>

>> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>

>> wrote:

>>

>>> Hi Bill,

>>>

>>> could you clarify if this "device" is related to devicetree as defined

>>> by Linaro (https://github.com/devicetree-org/devicetree-specification)

>>> or the devices that are in the scope of Christophe Millard, or some other

>>> device concept ?

>>>

>>

>> This is the Device ID proposal that Petri suggested at BKK16. It is not

>> related to devtree or any other specific taxonomy as the idea was to

>> establish an abstract "device" framework that would support both individual

>> sockets or multi-SoC environments. In odp-linux these are basically

>> placeholder functions as we don't have any cross-platform concept of NUMA.

>> The idea is that each individual platform that does support NUMA should be

>> able to map their native concepts into this framework to permit

>> applications to associate an internal odp_dev_t handle with named devices.

>>

>>

>>>

>>> FF

>>>

>>>

>>>

>>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

>>> wrote:

>>>

>>>> Ping. v3 of this patch is still awaiting review.

>>>>

>>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>>> <bill.fischofer@linaro.org> wrote:

>>>> > Add the odp_dev_id() API used for NUMA support

>>>> >

>>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>>> > ---

>>>> > Changes for v3:

>>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>>> >

>>>> > Changes for v2:

>>>> > - Incorporate changes suggested by Petri

>>>> >

>>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>>> ++++++++++++++++

>>>> >  1 file changed, 89 insertions(+)

>>>> >  create mode 100644 include/odp/api/spec/dev.h

>>>> >

>>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>>> > new file mode 100644

>>>> > index 0000000..76d861a

>>>> > --- /dev/null

>>>> > +++ b/include/odp/api/spec/dev.h

>>>> > @@ -0,0 +1,89 @@

>>>> > +/* Copyright (c) 2016, Linaro Limited

>>>> > + * All rights reserved.

>>>> > + *

>>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * @file

>>>> > + *

>>>> > + * ODP device

>>>> > + */

>>>> > +

>>>> > +#ifndef ODP_API_DEV_H_

>>>> > +#define ODP_API_DEV_H_

>>>> > +#include <odp/visibility_begin.h>

>>>> > +

>>>> > +#ifdef __cplusplus

>>>> > +extern "C" {

>>>> > +#endif

>>>> > +

>>>> > +#include <odp/api/std_types.h>

>>>> > +

>>>> > +/** @defgroup odp_dev ODP DEVICE

>>>> > + *  Operations on devices

>>>> > + *  @{

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * @typedef odp_dev_t

>>>> > + * ODP Device

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * @def ODP_DEV_NAME_LEN

>>>> > + * Maximum device name length in chars

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * @def ODP_DEV_DEFAULT

>>>> > + * Default device

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * @def ODP_DEV_INVALID

>>>> > + * Invalid device

>>>> > + */

>>>> > +

>>>> > +/**

>>>> > + * Get Device ID by Name

>>>> > + *

>>>> > + * Get an implementation-defined device identifier from a device

>>>> name. Device

>>>> > + * names are supplied as parameter info (command line, file, etc.)

>>>> to the

>>>> > + * application. This routine translates this symbolic name into an

>>>> internal

>>>> > + * identifier that can be used to define a device connection

>>>> hierarchy for

>>>> > + * NUMA or other purposes.

>>>> > + *

>>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>>> placeholder

>>>> > + * wherever a device id is required.

>>>> > + *

>>>> > + * @param name Name of the device

>>>> > + *

>>>> > + * @return Device ID

>>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>>> > + */

>>>> > +odp_dev_t odp_dev_id(const char *name);

>>>> > +

>>>> > +/**

>>>> > + * Get printable value for an odp_dev_t

>>>> > + *

>>>> > + * @param hdl  odp_dev_t handle to be printed

>>>> > + * @return     uint64_t value that can be used to print/display this

>>>> > + *             handle

>>>> > + *

>>>> > + * @note This routine is intended to be used for diagnostic purposes

>>>> > + * to enable applications to generate a printable value that

>>>> represents

>>>> > + * an odp_dev_t handle.

>>>> > + */

>>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>>> > +

>>>> > +/**

>>>> > + * @}

>>>> > + */

>>>> > +

>>>> > +#ifdef __cplusplus

>>>> > +}

>>>> > +#endif

>>>> > +

>>>> > +#include <odp/visibility_end.h>

>>>> > +#endif

>>>> > --

>>>> > 2.7.4

>>>> >

>>>>

>>>

>>>

>>>

>>> --

>>> [image: Linaro] <http://www.linaro.org/>

>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>> T: +33.67221.6485

>>> francois.ozog@linaro.org | Skype: ffozog

>>>

>>>

>>

>

>

> --

> [image: Linaro] <http://www.linaro.org/>

> François-Frédéric Ozog | *Director Linaro Networking Group*

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>
Francois Ozog Dec. 6, 2016, 3:05 p.m. | #7
OK. So let's defer the API but not the discussion.
I think we need a "strategic architecture" call.

FF



On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org>
wrote:

> I have no problem deferring this if we want to have one of the SoC vendors

> drive a more comprehensive approach based on their capabilities which can

> then be generalized. BTW, your link doesn't resolve. Typo somewhere?

>

> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

>> Devicetree has been formed by and for SoC vendors to represent what they

>> have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ

>> lines, firmware - http://free-electrons.com/pub/

>> conferences/2013/elce/petazzoni-device-tree-dummies/petazzon

>> i-device-tree-dummies.pdf)..... so it looks like very similar to what

>> Petri is talking about.

>>

>> ACPI has also a concept of a proximity domains and the relative cost to

>> use a resource from another domain.

>>

>> Handling NUMA requires a well thought through approach because it has

>> implications at many levels in particular for device and driver framework.

>>

>> Bottom line, regardless if it's value, the introduction of the API seem

>> too early as I haven't seen the use case that it supports and in particular

>> the device and drivers framework.

>>

>> FF

>>

>>

>>

>>

>>

>>

>> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>

>> wrote:

>>

>>>

>>>

>>> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>

>>> wrote:

>>>

>>>> Hi Bill,

>>>>

>>>> could you clarify if this "device" is related to devicetree as defined

>>>> by Linaro (https://github.com/devicetree-org/devicetree-specification)

>>>> or the devices that are in the scope of Christophe Millard, or some other

>>>> device concept ?

>>>>

>>>

>>> This is the Device ID proposal that Petri suggested at BKK16. It is not

>>> related to devtree or any other specific taxonomy as the idea was to

>>> establish an abstract "device" framework that would support both individual

>>> sockets or multi-SoC environments. In odp-linux these are basically

>>> placeholder functions as we don't have any cross-platform concept of NUMA.

>>> The idea is that each individual platform that does support NUMA should be

>>> able to map their native concepts into this framework to permit

>>> applications to associate an internal odp_dev_t handle with named devices.

>>>

>>>

>>>>

>>>> FF

>>>>

>>>>

>>>>

>>>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

>>>> wrote:

>>>>

>>>>> Ping. v3 of this patch is still awaiting review.

>>>>>

>>>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>>>> <bill.fischofer@linaro.org> wrote:

>>>>> > Add the odp_dev_id() API used for NUMA support

>>>>> >

>>>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>>>> > ---

>>>>> > Changes for v3:

>>>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>>>> >

>>>>> > Changes for v2:

>>>>> > - Incorporate changes suggested by Petri

>>>>> >

>>>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>>>> ++++++++++++++++

>>>>> >  1 file changed, 89 insertions(+)

>>>>> >  create mode 100644 include/odp/api/spec/dev.h

>>>>> >

>>>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>>>> > new file mode 100644

>>>>> > index 0000000..76d861a

>>>>> > --- /dev/null

>>>>> > +++ b/include/odp/api/spec/dev.h

>>>>> > @@ -0,0 +1,89 @@

>>>>> > +/* Copyright (c) 2016, Linaro Limited

>>>>> > + * All rights reserved.

>>>>> > + *

>>>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * @file

>>>>> > + *

>>>>> > + * ODP device

>>>>> > + */

>>>>> > +

>>>>> > +#ifndef ODP_API_DEV_H_

>>>>> > +#define ODP_API_DEV_H_

>>>>> > +#include <odp/visibility_begin.h>

>>>>> > +

>>>>> > +#ifdef __cplusplus

>>>>> > +extern "C" {

>>>>> > +#endif

>>>>> > +

>>>>> > +#include <odp/api/std_types.h>

>>>>> > +

>>>>> > +/** @defgroup odp_dev ODP DEVICE

>>>>> > + *  Operations on devices

>>>>> > + *  @{

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * @typedef odp_dev_t

>>>>> > + * ODP Device

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * @def ODP_DEV_NAME_LEN

>>>>> > + * Maximum device name length in chars

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * @def ODP_DEV_DEFAULT

>>>>> > + * Default device

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * @def ODP_DEV_INVALID

>>>>> > + * Invalid device

>>>>> > + */

>>>>> > +

>>>>> > +/**

>>>>> > + * Get Device ID by Name

>>>>> > + *

>>>>> > + * Get an implementation-defined device identifier from a device

>>>>> name. Device

>>>>> > + * names are supplied as parameter info (command line, file, etc.)

>>>>> to the

>>>>> > + * application. This routine translates this symbolic name into an

>>>>> internal

>>>>> > + * identifier that can be used to define a device connection

>>>>> hierarchy for

>>>>> > + * NUMA or other purposes.

>>>>> > + *

>>>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>>>> placeholder

>>>>> > + * wherever a device id is required.

>>>>> > + *

>>>>> > + * @param name Name of the device

>>>>> > + *

>>>>> > + * @return Device ID

>>>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>>>> > + */

>>>>> > +odp_dev_t odp_dev_id(const char *name);

>>>>> > +

>>>>> > +/**

>>>>> > + * Get printable value for an odp_dev_t

>>>>> > + *

>>>>> > + * @param hdl  odp_dev_t handle to be printed

>>>>> > + * @return     uint64_t value that can be used to print/display this

>>>>> > + *             handle

>>>>> > + *

>>>>> > + * @note This routine is intended to be used for diagnostic purposes

>>>>> > + * to enable applications to generate a printable value that

>>>>> represents

>>>>> > + * an odp_dev_t handle.

>>>>> > + */

>>>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>>>> > +

>>>>> > +/**

>>>>> > + * @}

>>>>> > + */

>>>>> > +

>>>>> > +#ifdef __cplusplus

>>>>> > +}

>>>>> > +#endif

>>>>> > +

>>>>> > +#include <odp/visibility_end.h>

>>>>> > +#endif

>>>>> > --

>>>>> > 2.7.4

>>>>> >

>>>>>

>>>>

>>>>

>>>>

>>>> --

>>>> [image: Linaro] <http://www.linaro.org/>

>>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>>> T: +33.67221.6485

>>>> francois.ozog@linaro.org | Skype: ffozog

>>>>

>>>>

>>>

>>

>>

>> --

>> [image: Linaro] <http://www.linaro.org/>

>> François-Frédéric Ozog | *Director Linaro Networking Group*

>> T: +33.67221.6485

>> francois.ozog@linaro.org | Skype: ffozog

>>

>>

>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Francois Ozog Dec. 6, 2016, 3:10 p.m. | #8
For the link, I think it ate the .... following it.
Here it is without decoration:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf



On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org> wrote:

> OK. So let's defer the API but not the discussion.

> I think we need a "strategic architecture" call.

>

> FF

>

>

>

> On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

>> I have no problem deferring this if we want to have one of the SoC

>> vendors drive a more comprehensive approach based on their capabilities

>> which can then be generalized. BTW, your link doesn't resolve. Typo

>> somewhere?

>>

>> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org>

>> wrote:

>>

>>> Devicetree has been formed by and for SoC vendors to represent what they

>>> have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ

>>> lines, firmware - http://free-electrons.com/pub/

>>> conferences/2013/elce/petazzoni-device-tree-dummies/petazzon

>>> i-device-tree-dummies.pdf)..... so it looks like very similar to what

>>> Petri is talking about.

>>>

>>> ACPI has also a concept of a proximity domains and the relative cost to

>>> use a resource from another domain.

>>>

>>> Handling NUMA requires a well thought through approach because it has

>>> implications at many levels in particular for device and driver framework.

>>>

>>> Bottom line, regardless if it's value, the introduction of the API seem

>>> too early as I haven't seen the use case that it supports and in particular

>>> the device and drivers framework.

>>>

>>> FF

>>>

>>>

>>>

>>>

>>>

>>>

>>> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>

>>> wrote:

>>>

>>>>

>>>>

>>>> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org

>>>> > wrote:

>>>>

>>>>> Hi Bill,

>>>>>

>>>>> could you clarify if this "device" is related to devicetree as defined

>>>>> by Linaro (https://github.com/devicetree-org/devicetree-specification)

>>>>> or the devices that are in the scope of Christophe Millard, or some other

>>>>> device concept ?

>>>>>

>>>>

>>>> This is the Device ID proposal that Petri suggested at BKK16. It is not

>>>> related to devtree or any other specific taxonomy as the idea was to

>>>> establish an abstract "device" framework that would support both individual

>>>> sockets or multi-SoC environments. In odp-linux these are basically

>>>> placeholder functions as we don't have any cross-platform concept of NUMA.

>>>> The idea is that each individual platform that does support NUMA should be

>>>> able to map their native concepts into this framework to permit

>>>> applications to associate an internal odp_dev_t handle with named devices.

>>>>

>>>>

>>>>>

>>>>> FF

>>>>>

>>>>>

>>>>>

>>>>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org

>>>>> > wrote:

>>>>>

>>>>>> Ping. v3 of this patch is still awaiting review.

>>>>>>

>>>>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>>>>> <bill.fischofer@linaro.org> wrote:

>>>>>> > Add the odp_dev_id() API used for NUMA support

>>>>>> >

>>>>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>>>>> > ---

>>>>>> > Changes for v3:

>>>>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>>>>> >

>>>>>> > Changes for v2:

>>>>>> > - Incorporate changes suggested by Petri

>>>>>> >

>>>>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>>>>> ++++++++++++++++

>>>>>> >  1 file changed, 89 insertions(+)

>>>>>> >  create mode 100644 include/odp/api/spec/dev.h

>>>>>> >

>>>>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>>>>> > new file mode 100644

>>>>>> > index 0000000..76d861a

>>>>>> > --- /dev/null

>>>>>> > +++ b/include/odp/api/spec/dev.h

>>>>>> > @@ -0,0 +1,89 @@

>>>>>> > +/* Copyright (c) 2016, Linaro Limited

>>>>>> > + * All rights reserved.

>>>>>> > + *

>>>>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @file

>>>>>> > + *

>>>>>> > + * ODP device

>>>>>> > + */

>>>>>> > +

>>>>>> > +#ifndef ODP_API_DEV_H_

>>>>>> > +#define ODP_API_DEV_H_

>>>>>> > +#include <odp/visibility_begin.h>

>>>>>> > +

>>>>>> > +#ifdef __cplusplus

>>>>>> > +extern "C" {

>>>>>> > +#endif

>>>>>> > +

>>>>>> > +#include <odp/api/std_types.h>

>>>>>> > +

>>>>>> > +/** @defgroup odp_dev ODP DEVICE

>>>>>> > + *  Operations on devices

>>>>>> > + *  @{

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @typedef odp_dev_t

>>>>>> > + * ODP Device

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @def ODP_DEV_NAME_LEN

>>>>>> > + * Maximum device name length in chars

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @def ODP_DEV_DEFAULT

>>>>>> > + * Default device

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @def ODP_DEV_INVALID

>>>>>> > + * Invalid device

>>>>>> > + */

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * Get Device ID by Name

>>>>>> > + *

>>>>>> > + * Get an implementation-defined device identifier from a device

>>>>>> name. Device

>>>>>> > + * names are supplied as parameter info (command line, file, etc.)

>>>>>> to the

>>>>>> > + * application. This routine translates this symbolic name into an

>>>>>> internal

>>>>>> > + * identifier that can be used to define a device connection

>>>>>> hierarchy for

>>>>>> > + * NUMA or other purposes.

>>>>>> > + *

>>>>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>>>>> placeholder

>>>>>> > + * wherever a device id is required.

>>>>>> > + *

>>>>>> > + * @param name Name of the device

>>>>>> > + *

>>>>>> > + * @return Device ID

>>>>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>>>>> > + */

>>>>>> > +odp_dev_t odp_dev_id(const char *name);

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * Get printable value for an odp_dev_t

>>>>>> > + *

>>>>>> > + * @param hdl  odp_dev_t handle to be printed

>>>>>> > + * @return     uint64_t value that can be used to print/display

>>>>>> this

>>>>>> > + *             handle

>>>>>> > + *

>>>>>> > + * @note This routine is intended to be used for diagnostic

>>>>>> purposes

>>>>>> > + * to enable applications to generate a printable value that

>>>>>> represents

>>>>>> > + * an odp_dev_t handle.

>>>>>> > + */

>>>>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>>>>> > +

>>>>>> > +/**

>>>>>> > + * @}

>>>>>> > + */

>>>>>> > +

>>>>>> > +#ifdef __cplusplus

>>>>>> > +}

>>>>>> > +#endif

>>>>>> > +

>>>>>> > +#include <odp/visibility_end.h>

>>>>>> > +#endif

>>>>>> > --

>>>>>> > 2.7.4

>>>>>> >

>>>>>>

>>>>>

>>>>>

>>>>>

>>>>> --

>>>>> [image: Linaro] <http://www.linaro.org/>

>>>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>>>> T: +33.67221.6485

>>>>> francois.ozog@linaro.org | Skype: ffozog

>>>>>

>>>>>

>>>>

>>>

>>>

>>> --

>>> [image: Linaro] <http://www.linaro.org/>

>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>> T: +33.67221.6485

>>> francois.ozog@linaro.org | Skype: ffozog

>>>

>>>

>>

>

>

> --

> [image: Linaro] <http://www.linaro.org/>

> François-Frédéric Ozog | *Director Linaro Networking Group*

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>



-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Honnappa Nagarahalli Dec. 6, 2016, 5:08 p.m. | #9
Hi Bill,
    Do you have any slides/docs on Petri's suggestion?

Thank you,
Honnappa

On 6 December 2016 at 09:10, Francois Ozog <francois.ozog@linaro.org> wrote:
> For the link, I think it ate the .... following it.

> Here it is without decoration:

> http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

>

>

>

> On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org> wrote:

>

>> OK. So let's defer the API but not the discussion.

>> I think we need a "strategic architecture" call.

>>

>> FF

>>

>>

>>

>> On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org>

>> wrote:

>>

>>> I have no problem deferring this if we want to have one of the SoC

>>> vendors drive a more comprehensive approach based on their capabilities

>>> which can then be generalized. BTW, your link doesn't resolve. Typo

>>> somewhere?

>>>

>>> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org>

>>> wrote:

>>>

>>>> Devicetree has been formed by and for SoC vendors to represent what they

>>>> have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ

>>>> lines, firmware - http://free-electrons.com/pub/

>>>> conferences/2013/elce/petazzoni-device-tree-dummies/petazzon

>>>> i-device-tree-dummies.pdf)..... so it looks like very similar to what

>>>> Petri is talking about.

>>>>

>>>> ACPI has also a concept of a proximity domains and the relative cost to

>>>> use a resource from another domain.

>>>>

>>>> Handling NUMA requires a well thought through approach because it has

>>>> implications at many levels in particular for device and driver framework.

>>>>

>>>> Bottom line, regardless if it's value, the introduction of the API seem

>>>> too early as I haven't seen the use case that it supports and in particular

>>>> the device and drivers framework.

>>>>

>>>> FF

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>

>>>> wrote:

>>>>

>>>>>

>>>>>

>>>>> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org

>>>>> > wrote:

>>>>>

>>>>>> Hi Bill,

>>>>>>

>>>>>> could you clarify if this "device" is related to devicetree as defined

>>>>>> by Linaro (https://github.com/devicetree-org/devicetree-specification)

>>>>>> or the devices that are in the scope of Christophe Millard, or some other

>>>>>> device concept ?

>>>>>>

>>>>>

>>>>> This is the Device ID proposal that Petri suggested at BKK16. It is not

>>>>> related to devtree or any other specific taxonomy as the idea was to

>>>>> establish an abstract "device" framework that would support both individual

>>>>> sockets or multi-SoC environments. In odp-linux these are basically

>>>>> placeholder functions as we don't have any cross-platform concept of NUMA.

>>>>> The idea is that each individual platform that does support NUMA should be

>>>>> able to map their native concepts into this framework to permit

>>>>> applications to associate an internal odp_dev_t handle with named devices.

>>>>>

>>>>>

>>>>>>

>>>>>> FF

>>>>>>

>>>>>>

>>>>>>

>>>>>> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org

>>>>>> > wrote:

>>>>>>

>>>>>>> Ping. v3 of this patch is still awaiting review.

>>>>>>>

>>>>>>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

>>>>>>> <bill.fischofer@linaro.org> wrote:

>>>>>>> > Add the odp_dev_id() API used for NUMA support

>>>>>>> >

>>>>>>> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>>>>>>> > ---

>>>>>>> > Changes for v3:

>>>>>>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>>>>>> >

>>>>>>> > Changes for v2:

>>>>>>> > - Incorporate changes suggested by Petri

>>>>>>> >

>>>>>>> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

>>>>>>> ++++++++++++++++

>>>>>>> >  1 file changed, 89 insertions(+)

>>>>>>> >  create mode 100644 include/odp/api/spec/dev.h

>>>>>>> >

>>>>>>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>>>>>>> > new file mode 100644

>>>>>>> > index 0000000..76d861a

>>>>>>> > --- /dev/null

>>>>>>> > +++ b/include/odp/api/spec/dev.h

>>>>>>> > @@ -0,0 +1,89 @@

>>>>>>> > +/* Copyright (c) 2016, Linaro Limited

>>>>>>> > + * All rights reserved.

>>>>>>> > + *

>>>>>>> > + * SPDX-License-Identifier:     BSD-3-Clause

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @file

>>>>>>> > + *

>>>>>>> > + * ODP device

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +#ifndef ODP_API_DEV_H_

>>>>>>> > +#define ODP_API_DEV_H_

>>>>>>> > +#include <odp/visibility_begin.h>

>>>>>>> > +

>>>>>>> > +#ifdef __cplusplus

>>>>>>> > +extern "C" {

>>>>>>> > +#endif

>>>>>>> > +

>>>>>>> > +#include <odp/api/std_types.h>

>>>>>>> > +

>>>>>>> > +/** @defgroup odp_dev ODP DEVICE

>>>>>>> > + *  Operations on devices

>>>>>>> > + *  @{

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @typedef odp_dev_t

>>>>>>> > + * ODP Device

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @def ODP_DEV_NAME_LEN

>>>>>>> > + * Maximum device name length in chars

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @def ODP_DEV_DEFAULT

>>>>>>> > + * Default device

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @def ODP_DEV_INVALID

>>>>>>> > + * Invalid device

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * Get Device ID by Name

>>>>>>> > + *

>>>>>>> > + * Get an implementation-defined device identifier from a device

>>>>>>> name. Device

>>>>>>> > + * names are supplied as parameter info (command line, file, etc.)

>>>>>>> to the

>>>>>>> > + * application. This routine translates this symbolic name into an

>>>>>>> internal

>>>>>>> > + * identifier that can be used to define a device connection

>>>>>>> hierarchy for

>>>>>>> > + * NUMA or other purposes.

>>>>>>> > + *

>>>>>>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

>>>>>>> placeholder

>>>>>>> > + * wherever a device id is required.

>>>>>>> > + *

>>>>>>> > + * @param name Name of the device

>>>>>>> > + *

>>>>>>> > + * @return Device ID

>>>>>>> > + * @retval ODP_DEV_INVALID Device is unknown

>>>>>>> > + */

>>>>>>> > +odp_dev_t odp_dev_id(const char *name);

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * Get printable value for an odp_dev_t

>>>>>>> > + *

>>>>>>> > + * @param hdl  odp_dev_t handle to be printed

>>>>>>> > + * @return     uint64_t value that can be used to print/display

>>>>>>> this

>>>>>>> > + *             handle

>>>>>>> > + *

>>>>>>> > + * @note This routine is intended to be used for diagnostic

>>>>>>> purposes

>>>>>>> > + * to enable applications to generate a printable value that

>>>>>>> represents

>>>>>>> > + * an odp_dev_t handle.

>>>>>>> > + */

>>>>>>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>>>>>>> > +

>>>>>>> > +/**

>>>>>>> > + * @}

>>>>>>> > + */

>>>>>>> > +

>>>>>>> > +#ifdef __cplusplus

>>>>>>> > +}

>>>>>>> > +#endif

>>>>>>> > +

>>>>>>> > +#include <odp/visibility_end.h>

>>>>>>> > +#endif

>>>>>>> > --

>>>>>>> > 2.7.4

>>>>>>> >

>>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>> --

>>>>>> [image: Linaro] <http://www.linaro.org/>

>>>>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>>>>> T: +33.67221.6485

>>>>>> francois.ozog@linaro.org | Skype: ffozog

>>>>>>

>>>>>>

>>>>>

>>>>

>>>>

>>>> --

>>>> [image: Linaro] <http://www.linaro.org/>

>>>> François-Frédéric Ozog | *Director Linaro Networking Group*

>>>> T: +33.67221.6485

>>>> francois.ozog@linaro.org | Skype: ffozog

>>>>

>>>>

>>>

>>

>>

>> --

>> [image: Linaro] <http://www.linaro.org/>

>> François-Frédéric Ozog | *Director Linaro Networking Group*

>> T: +33.67221.6485

>> francois.ozog@linaro.org | Skype: ffozog

>>

>>

>

>

> --

> [image: Linaro] <http://www.linaro.org/>

> François-Frédéric Ozog | *Director Linaro Networking Group*

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog
Savolainen, Petri (Nokia - FI/Espoo) Dec. 7, 2016, 11:13 a.m. | #10
I know device trees and how ugly those can be ….  values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean…

Anyway, the idea here is that

·         an implementation has a way to enumerate resources to the user as names

o   a name may come from a standard or system specific tool (ifconfig), a configuration file (even device trees), etc. API does not dictate how user gets a resource name, or which kind of string  that name is.

·         User passes the name to the application (through command line, config file, env variable). API don’t dictate how that happens.

·         Application passes the name to the implementation and gets a device ID (odp_dev_t), which it uses as a parameter on other calls

Resource discovery/enumeration/management/etc is left to upper layer. API is only needed for passing resource identifier information down to the  implementation. And this is how it should be: ODP is a passive library which does what it’s told to do, the active role is on upper layers (user, scripts, resource management SW, etc entity).

So, no need to defer the API since it’s flexible enough (to pass any kind of string down to implementation). Driver, cloud, etc frameworks may then specify the dev name string format, etc later on, but it would not change the API if a timer is called “timer0” or “timer0:2” or “/proc/soc/0/timer/1” or something else.

-Petri



From: Francois Ozog [mailto:francois.ozog@linaro.org]

Sent: Tuesday, December 06, 2016 5:10 PM
To: Bill Fischofer <bill.fischofer@linaro.org>
Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; Christophe Milard <christophe.milard@linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

For the link, I think it ate the .... following it.
Here it is without decoration:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf



On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org<mailto:francois.ozog@linaro.org>> wrote:
OK. So let's defer the API but not the discussion.
I think we need a "strategic architecture" call.

FF



On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:
I have no problem deferring this if we want to have one of the SoC vendors drive a more comprehensive approach based on their capabilities which can then be generalized. BTW, your link doesn't resolve. Typo somewhere?

On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org<mailto:francois.ozog@linaro.org>> wrote:
Devicetree has been formed by and for SoC vendors to represent what they have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so it looks like very similar to what Petri is talking about.

ACPI has also a concept of a proximity domains and the relative cost to use a resource from another domain.

Handling NUMA requires a well thought through approach because it has implications at many levels in particular for device and driver framework.

Bottom line, regardless if it's value, the introduction of the API seem too early as I haven't seen the use case that it supports and in particular the device and drivers framework.

FF






On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:


On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org<mailto:francois.ozog@linaro.org>> wrote:
Hi Bill,

could you clarify if this "device" is related to devicetree as defined by Linaro (https://github.com/devicetree-org/devicetree-specification) or the devices that are in the scope of Christophe Millard, or some other device concept ?

This is the Device ID proposal that Petri suggested at BKK16. It is not related to devtree or any other specific taxonomy as the idea was to establish an abstract "device" framework that would support both individual sockets or multi-SoC environments. In odp-linux these are basically placeholder functions as we don't have any cross-platform concept of NUMA. The idea is that each individual platform that does support NUMA should be able to map their native concepts into this framework to permit applications to associate an internal odp_dev_t handle with named devices.


FF



On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:
Ping. v3 of this patch is still awaiting review.

On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer
<bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:
> Add the odp_dev_id() API used for NUMA support

>

> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>

> ---

> Changes for v3:

> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>

> Changes for v2:

> - Incorporate changes suggested by Petri

>

>  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++

>  1 file changed, 89 insertions(+)

>  create mode 100644 include/odp/api/spec/dev.h

>

> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> new file mode 100644

> index 0000000..76d861a

> --- /dev/null

> +++ b/include/odp/api/spec/dev.h

> @@ -0,0 +1,89 @@

> +/* Copyright (c) 2016, Linaro Limited

> + * All rights reserved.

> + *

> + * SPDX-License-Identifier:     BSD-3-Clause

> + */

> +

> +/**

> + * @file

> + *

> + * ODP device

> + */

> +

> +#ifndef ODP_API_DEV_H_

> +#define ODP_API_DEV_H_

> +#include <odp/visibility_begin.h>

> +

> +#ifdef __cplusplus

> +extern "C" {

> +#endif

> +

> +#include <odp/api/std_types.h>

> +

> +/** @defgroup odp_dev ODP DEVICE

> + *  Operations on devices

> + *  @{

> + */

> +

> +/**

> + * @typedef odp_dev_t

> + * ODP Device

> + */

> +

> +/**

> + * @def ODP_DEV_NAME_LEN

> + * Maximum device name length in chars

> + */

> +

> +/**

> + * @def ODP_DEV_DEFAULT

> + * Default device

> + */

> +

> +/**

> + * @def ODP_DEV_INVALID

> + * Invalid device

> + */

> +

> +/**

> + * Get Device ID by Name

> + *

> + * Get an implementation-defined device identifier from a device name. Device

> + * names are supplied as parameter info (command line, file, etc.) to the

> + * application. This routine translates this symbolic name into an internal

> + * identifier that can be used to define a device connection hierarchy for

> + * NUMA or other purposes.

> + *

> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder

> + * wherever a device id is required.

> + *

> + * @param name Name of the device

> + *

> + * @return Device ID

> + * @retval ODP_DEV_INVALID Device is unknown

> + */

> +odp_dev_t odp_dev_id(const char *name);

> +

> +/**

> + * Get printable value for an odp_dev_t

> + *

> + * @param hdl  odp_dev_t handle to be printed

> + * @return     uint64_t value that can be used to print/display this

> + *             handle

> + *

> + * @note This routine is intended to be used for diagnostic purposes

> + * to enable applications to generate a printable value that represents

> + * an odp_dev_t handle.

> + */

> +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> +

> +/**

> + * @}

> + */

> +

> +#ifdef __cplusplus

> +}

> +#endif

> +

> +#include <odp/visibility_end.h>

> +#endif

> --

> 2.7.4

>




--
[Image removed by sender. Linaro]<http://www.linaro.org/>

François-Frédéric Ozog | Director Linaro Networking Group

T: +33.67221.6485<tel:%2B33.67221.6485>
francois.ozog@linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog







--
[Image removed by sender. Linaro]<http://www.linaro.org/>

François-Frédéric Ozog | Director Linaro Networking Group

T: +33.67221.6485<tel:%2B33.67221.6485>
francois.ozog@linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog







--
[Image removed by sender. Linaro]<http://www.linaro.org/>

François-Frédéric Ozog | Director Linaro Networking Group

T: +33.67221.6485<tel:%2B33.67221.6485>
francois.ozog@linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog






--
[Image removed by sender. Linaro]<http://www.linaro.org/>

François-Frédéric Ozog | Director Linaro Networking Group

T: +33.67221.6485<tel:%2B33.67221.6485>
francois.ozog@linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
Savolainen, Petri (Nokia - FI/Espoo) Dec. 7, 2016, 11:32 a.m. | #11
... sending again as plain text ...

I know device trees and how ugly those can be ….  values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean…

Anyway, the idea here is that
• an implementation has a way to enumerate resources to the user as names
o a name may come from a standard or system specific tool (ifconfig), a configuration file (even device trees), etc. API does not dictate how user gets a resource name, or which kind of string  that name is.
• User passes the name to the application (through command line, config file, env variable). API don’t dictate how that happens.
• Application passes the name to the implementation and gets a device ID (odp_dev_t), which it uses as a parameter on other calls

Resource discovery/enumeration/management/etc is left to upper layer. API is only needed for passing resource identifier information down to the  implementation. And this is how it should be: ODP is a passive library which does what it’s told to do, the active role is on upper layers (user, scripts, resource management SW, etc entity).

So, no need to defer the API since it’s flexible enough (to pass any kind of string down to implementation). Driver, cloud, etc frameworks may then specify the dev name string format, etc later on, but it would not change the API if a timer is called “timer0” or “timer0:2” or “/proc/soc/0/timer/1” or something else.

-Petri



From: Francois Ozog [mailto:francois.ozog@linaro.org] 

Sent: Tuesday, December 06, 2016 5:10 PM
To: Bill Fischofer <bill.fischofer@linaro.org>
Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; Christophe Milard <christophe.milard@linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

For the link, I think it ate the .... following it.
Here it is without decoration:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf



On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org> wrote:
OK. So let's defer the API but not the discussion.
I think we need a "strategic architecture" call. 

FF



On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org> wrote:
I have no problem deferring this if we want to have one of the SoC vendors drive a more comprehensive approach based on their capabilities which can then be generalized. BTW, your link doesn't resolve. Typo somewhere?

On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org> wrote:
Devicetree has been formed by and for SoC vendors to represent what they have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so it looks like very similar to what Petri is talking about.  

ACPI has also a concept of a proximity domains and the relative cost to use a resource from another domain.

Handling NUMA requires a well thought through approach because it has implications at many levels in particular for device and driver framework.

Bottom line, regardless if it's value, the introduction of the API seem too early as I haven't seen the use case that it supports and in particular the device and drivers framework.

FF






On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org> wrote:


On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org> wrote:
Hi Bill,

could you clarify if this "device" is related to devicetree as defined by Linaro (https://github.com/devicetree-org/devicetree-specification) or the devices that are in the scope of Christophe Millard, or some other device concept ?

This is the Device ID proposal that Petri suggested at BKK16. It is not related to devtree or any other specific taxonomy as the idea was to establish an abstract "device" framework that would support both individual sockets or multi-SoC environments. In odp-linux these are basically placeholder functions as we don't have any cross-platform concept of NUMA. The idea is that each individual platform that does support NUMA should be able to map their native concepts into this framework to permit applications to associate an internal odp_dev_t handle with named devices.
 

FF



On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org> wrote:
Ping. v3 of this patch is still awaiting review.

On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer
<bill.fischofer@linaro.org> wrote:
> Add the odp_dev_id() API used for NUMA support

>

> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

> ---

> Changes for v3:

> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>

> Changes for v2:

> - Incorporate changes suggested by Petri

>

>  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++

>  1 file changed, 89 insertions(+)

>  create mode 100644 include/odp/api/spec/dev.h

>

> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> new file mode 100644

> index 0000000..76d861a

> --- /dev/null

> +++ b/include/odp/api/spec/dev.h

> @@ -0,0 +1,89 @@

> +/* Copyright (c) 2016, Linaro Limited

> + * All rights reserved.

> + *

> + * SPDX-License-Identifier:     BSD-3-Clause

> + */

> +

> +/**

> + * @file

> + *

> + * ODP device

> + */

> +

> +#ifndef ODP_API_DEV_H_

> +#define ODP_API_DEV_H_

> +#include <odp/visibility_begin.h>

> +

> +#ifdef __cplusplus

> +extern "C" {

> +#endif

> +

> +#include <odp/api/std_types.h>

> +

> +/** @defgroup odp_dev ODP DEVICE

> + *  Operations on devices

> + *  @{

> + */

> +

> +/**

> + * @typedef odp_dev_t

> + * ODP Device

> + */

> +

> +/**

> + * @def ODP_DEV_NAME_LEN

> + * Maximum device name length in chars

> + */

> +

> +/**

> + * @def ODP_DEV_DEFAULT

> + * Default device

> + */

> +

> +/**

> + * @def ODP_DEV_INVALID

> + * Invalid device

> + */

> +

> +/**

> + * Get Device ID by Name

> + *

> + * Get an implementation-defined device identifier from a device name. Device

> + * names are supplied as parameter info (command line, file, etc.) to the

> + * application. This routine translates this symbolic name into an internal

> + * identifier that can be used to define a device connection hierarchy for

> + * NUMA or other purposes.

> + *

> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder

> + * wherever a device id is required.

> + *

> + * @param name Name of the device

> + *

> + * @return Device ID

> + * @retval ODP_DEV_INVALID Device is unknown

> + */

> +odp_dev_t odp_dev_id(const char *name);

> +

> +/**

> + * Get printable value for an odp_dev_t

> + *

> + * @param hdl  odp_dev_t handle to be printed

> + * @return     uint64_t value that can be used to print/display this

> + *             handle

> + *

> + * @note This routine is intended to be used for diagnostic purposes

> + * to enable applications to generate a printable value that represents

> + * an odp_dev_t handle.

> + */

> +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> +

> +/**

> + * @}

> + */

> +

> +#ifdef __cplusplus

> +}

> +#endif

> +

> +#include <odp/visibility_end.h>

> +#endif

> --

> 2.7.4

>





-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog







-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog







-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog






-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Francois Ozog Dec. 7, 2016, 11:33 a.m. | #12
Well, we need to formalize the scope and it looks like this is part of the
Device and Driver Framework (DDF) that Christophe works on.

I have asked Christophe to create a document complementing the patches it
pushed so that we have a human readable reference on what the DDF does and
the general mechanics of it.

For instance the DDF can build a "physical" view of things through the
various device enumerators (from DT to DPAA2 including ACPi, PCI, virtual,
static...). But applications should not care about that. They may care of a
"functional representation" derived from that hardware aspect. For instance
controlling SFP aspects of a port may require controlling a specific PCI
device ID while the port itself is under the control of another PCI device
ID.
Additional information can be found here:
https://docs.google.com/a/linaro.org/presentation/d/1Ecb9-jA_7jbXtgMVImiTePzpOJsa6IldZMeFdjG8ypQ/edit?usp=sharing

So until we know how (or even if) the proposed API fits in a functional
framework (how it is used by what - application, odp internal, drivers
only...) this is premature to introduce it.

FF


On 7 December 2016 at 12:13, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolainen@nokia-bell-labs.com> wrote:

> I know device trees and how ugly those can be ….  values are not

> documented but you (your driver) just have to know what some list of four

> integers (reg = <4, 78865, 6, 565>) may actually mean…

>

>

>

> Anyway, the idea here is that

>

> ·         an implementation has a way to enumerate resources to the user

> as names

>

> o   a name may come from a standard or system specific tool (ifconfig), a

> configuration file (even device trees), etc. API does not dictate how user

> gets a resource name, or which kind of string  that name is.

>

> ·         User passes the name to the application (through command line,

> config file, env variable). API don’t dictate how that happens.

>

> ·         Application passes the name to the implementation and gets a

> device ID (odp_dev_t), which it uses as a parameter on other calls

>

>

>

> Resource discovery/enumeration/management/etc is left to upper layer. API

> is only needed for passing resource identifier information down to the

>  implementation. And this is how it should be: ODP is a passive library

> which does what it’s told to do, the active role is on upper layers (user,

> scripts, resource management SW, etc entity).

>

>

>

> So, no need to defer the API since it’s flexible enough (to pass any kind

> of string down to implementation). Driver, cloud, etc frameworks may then

> specify the dev name string format, etc later on, but it would not change

> the API if a timer is called “timer0” or “timer0:2” or

> “/proc/soc/0/timer/1” or something else.

>

>

>

> -Petri

>

>

>

>

>

>

>

> *From:* Francois Ozog [mailto:francois.ozog@linaro.org]

> *Sent:* Tuesday, December 06, 2016 5:10 PM

> *To:* Bill Fischofer <bill.fischofer@linaro.org>

> *Cc:* lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri

> (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; Christophe

> Milard <christophe.milard@linaro.org>

> *Subject:* Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis

> for numa support

>

>

>

> For the link, I think it ate the .... following it.

>

> Here it is without decoration:

>

> http://free-electrons.com/pub/conferences/2013/elce/

> petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

>

>

>

>

>

>

>

> On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

> OK. So let's defer the API but not the discussion.

>

> I think we need a "strategic architecture" call.

>

>

>

> FF

>

>

>

>

>

>

>

> On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

> I have no problem deferring this if we want to have one of the SoC vendors

> drive a more comprehensive approach based on their capabilities which can

> then be generalized. BTW, your link doesn't resolve. Typo somewhere?

>

>

>

> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

> Devicetree has been formed by and for SoC vendors to represent what they

> have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ

> lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/

> petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so

> it looks like very similar to what Petri is talking about.

>

>

>

> ACPI has also a concept of a proximity domains and the relative cost to

> use a resource from another domain.

>

>

>

> Handling NUMA requires a well thought through approach because it has

> implications at many levels in particular for device and driver framework.

>

>

>

> Bottom line, regardless if it's value, the introduction of the API seem

> too early as I haven't seen the use case that it supports and in particular

> the device and drivers framework.

>

>

>

> FF

>

>

>

>

>

>

>

>

>

>

>

>

>

> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

>

>

>

>

> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org>

> wrote:

>

> Hi Bill,

>

>

>

> could you clarify if this "device" is related to devicetree as defined by

> Linaro (https://github.com/devicetree-org/devicetree-specification) or

> the devices that are in the scope of Christophe Millard, or some other

> device concept ?

>

>

>

> This is the Device ID proposal that Petri suggested at BKK16. It is not

> related to devtree or any other specific taxonomy as the idea was to

> establish an abstract "device" framework that would support both individual

> sockets or multi-SoC environments. In odp-linux these are basically

> placeholder functions as we don't have any cross-platform concept of NUMA.

> The idea is that each individual platform that does support NUMA should be

> able to map their native concepts into this framework to permit

> applications to associate an internal odp_dev_t handle with named devices.

>

>

>

>

>

> FF

>

>

>

>

>

>

>

> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org>

> wrote:

>

> Ping. v3 of this patch is still awaiting review.

>

>

> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

> <bill.fischofer@linaro.org> wrote:

> > Add the odp_dev_id() API used for NUMA support

> >

> > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

> > ---

> > Changes for v3:

> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

> >

> > Changes for v2:

> > - Incorporate changes suggested by Petri

> >

> >  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++

> ++++++++++++++++

> >  1 file changed, 89 insertions(+)

> >  create mode 100644 include/odp/api/spec/dev.h

> >

> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> > new file mode 100644

> > index 0000000..76d861a

> > --- /dev/null

> > +++ b/include/odp/api/spec/dev.h

> > @@ -0,0 +1,89 @@

> > +/* Copyright (c) 2016, Linaro Limited

> > + * All rights reserved.

> > + *

> > + * SPDX-License-Identifier:     BSD-3-Clause

> > + */

> > +

> > +/**

> > + * @file

> > + *

> > + * ODP device

> > + */

> > +

> > +#ifndef ODP_API_DEV_H_

> > +#define ODP_API_DEV_H_

> > +#include <odp/visibility_begin.h>

> > +

> > +#ifdef __cplusplus

> > +extern "C" {

> > +#endif

> > +

> > +#include <odp/api/std_types.h>

> > +

> > +/** @defgroup odp_dev ODP DEVICE

> > + *  Operations on devices

> > + *  @{

> > + */

> > +

> > +/**

> > + * @typedef odp_dev_t

> > + * ODP Device

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_NAME_LEN

> > + * Maximum device name length in chars

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_DEFAULT

> > + * Default device

> > + */

> > +

> > +/**

> > + * @def ODP_DEV_INVALID

> > + * Invalid device

> > + */

> > +

> > +/**

> > + * Get Device ID by Name

> > + *

> > + * Get an implementation-defined device identifier from a device name.

> Device

> > + * names are supplied as parameter info (command line, file, etc.) to

> the

> > + * application. This routine translates this symbolic name into an

> internal

> > + * identifier that can be used to define a device connection hierarchy

> for

> > + * NUMA or other purposes.

> > + *

> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care"

> placeholder

> > + * wherever a device id is required.

> > + *

> > + * @param name Name of the device

> > + *

> > + * @return Device ID

> > + * @retval ODP_DEV_INVALID Device is unknown

> > + */

> > +odp_dev_t odp_dev_id(const char *name);

> > +

> > +/**

> > + * Get printable value for an odp_dev_t

> > + *

> > + * @param hdl  odp_dev_t handle to be printed

> > + * @return     uint64_t value that can be used to print/display this

> > + *             handle

> > + *

> > + * @note This routine is intended to be used for diagnostic purposes

> > + * to enable applications to generate a printable value that represents

> > + * an odp_dev_t handle.

> > + */

> > +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> > +

> > +/**

> > + * @}

> > + */

> > +

> > +#ifdef __cplusplus

> > +}

> > +#endif

> > +

> > +#include <odp/visibility_end.h>

> > +#endif

> > --

> > 2.7.4

> >

>

>

>

>

>

> --

>

> [image: Image removed by sender. Linaro] <http://www.linaro.org/>

>

> *François-Frédéric Ozog* | *Director Linaro Networking Group*

>

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

>

>

>

> --

>

> [image: Image removed by sender. Linaro] <http://www.linaro.org/>

>

> *François-Frédéric Ozog* | *Director Linaro Networking Group*

>

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

>

>

>

> --

>

> [image: Image removed by sender. Linaro] <http://www.linaro.org/>

>

> *François-Frédéric Ozog* | *Director Linaro Networking Group*

>

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

>

> --

>

> [image: Image removed by sender. Linaro] <http://www.linaro.org/>

>

> *François-Frédéric Ozog* | *Director Linaro Networking Group*

>

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>




-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Savolainen, Petri (Nokia - FI/Espoo) Dec. 7, 2016, 12:09 p.m. | #13
DDF may be part of some implementations, but it's not compulsory. So, DFF must be able utilize dev API, but dev API does not depend on DDF. Dev API needs to provide freedom of implementation.

Weather a device is behind PCI or not (or if SFP is used or not) is far beyond the API level. Application may ask to open "eth0" or "eth10g_backplane", which is the name of an Ethernet port on the blade (on the system). Implementation knows which driver to use for that interface (from system configuration, etc), application does not need to know about drivers or other implementation details of the interface.  

-Petri


From: Francois Ozog [mailto:francois.ozog@linaro.org] 

Sent: Wednesday, December 07, 2016 1:34 PM
To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>
Cc: Bill Fischofer <bill.fischofer@linaro.org>; lng-odp-forward <lng-odp@lists.linaro.org>; Christophe Milard <christophe.milard@linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

Well, we need to formalize the scope and it looks like this is part of the Device and Driver Framework (DDF) that Christophe works on.

I have asked Christophe to create a document complementing the patches it pushed so that we have a human readable reference on what the DDF does and the general mechanics of it.

For instance the DDF can build a "physical" view of things through the various device enumerators (from DT to DPAA2 including ACPi, PCI, virtual, static...). But applications should not care about that. They may care of a "functional representation" derived from that hardware aspect. For instance controlling SFP aspects of a port may require controlling a specific PCI device ID while the port itself is under the control of another PCI device ID.
Additional information can be found here: https://docs.google.com/a/linaro.org/presentation/d/1Ecb9-jA_7jbXtgMVImiTePzpOJsa6IldZMeFdjG8ypQ/edit?usp=sharing

So until we know how (or even if) the proposed API fits in a functional framework (how it is used by what - application, odp internal, drivers only...) this is premature to introduce it.

FF


On 7 December 2016 at 12:13, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com> wrote:
I know device trees and how ugly those can be ….  values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean…
 
Anyway, the idea here is that
•         an implementation has a way to enumerate resources to the user as names
o   a name may come from a standard or system specific tool (ifconfig), a configuration file (even device trees), etc. API does not dictate how user gets a resource name, or which kind of string  that name is.
•         User passes the name to the application (through command line, config file, env variable). API don’t dictate how that happens.
•         Application passes the name to the implementation and gets a device ID (odp_dev_t), which it uses as a parameter on other calls
 
Resource discovery/enumeration/management/etc is left to upper layer. API is only needed for passing resource identifier information down to the  implementation. And this is how it should be: ODP is a passive library which does what it’s told to do, the active role is on upper layers (user, scripts, resource management SW, etc entity).
 
So, no need to defer the API since it’s flexible enough (to pass any kind of string down to implementation). Driver, cloud, etc frameworks may then specify the dev name string format, etc later on, but it would not change the API if a timer is called “timer0” or “timer0:2” or “/proc/soc/0/timer/1” or something else.
 
-Petri
 
 
 
From: Francois Ozog [mailto:francois.ozog@linaro.org] 

Sent: Tuesday, December 06, 2016 5:10 PM
To: Bill Fischofer <bill.fischofer@linaro.org>
Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; Christophe Milard <christophe.milard@linaro.org>
Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support
 
For the link, I think it ate the .... following it.
Here it is without decoration:
http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf
 
 
 
On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org> wrote:
OK. So let's defer the API but not the discussion.
I think we need a "strategic architecture" call. 
 
FF
 
 
 
On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org> wrote:
I have no problem deferring this if we want to have one of the SoC vendors drive a more comprehensive approach based on their capabilities which can then be generalized. BTW, your link doesn't resolve. Typo somewhere?
 
On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org> wrote:
Devicetree has been formed by and for SoC vendors to represent what they have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so it looks like very similar to what Petri is talking about.  
 
ACPI has also a concept of a proximity domains and the relative cost to use a resource from another domain.
 
Handling NUMA requires a well thought through approach because it has implications at many levels in particular for device and driver framework.
 
Bottom line, regardless if it's value, the introduction of the API seem too early as I haven't seen the use case that it supports and in particular the device and drivers framework.
 
FF
 
 
 
 
 
 
On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org> wrote:
 
 
On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org> wrote:
Hi Bill,
 
could you clarify if this "device" is related to devicetree as defined by Linaro (https://github.com/devicetree-org/devicetree-specification) or the devices that are in the scope of Christophe Millard, or some other device concept ?
 
This is the Device ID proposal that Petri suggested at BKK16. It is not related to devtree or any other specific taxonomy as the idea was to establish an abstract "device" framework that would support both individual sockets or multi-SoC environments. In odp-linux these are basically placeholder functions as we don't have any cross-platform concept of NUMA. The idea is that each individual platform that does support NUMA should be able to map their native concepts into this framework to permit applications to associate an internal odp_dev_t handle with named devices.
 
 
FF
 
 
 
On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org> wrote:
Ping. v3 of this patch is still awaiting review.

On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer
<bill.fischofer@linaro.org> wrote:
> Add the odp_dev_id() API used for NUMA support

>

> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

> ---

> Changes for v3:

> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>

> Changes for v2:

> - Incorporate changes suggested by Petri

>

>  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++

>  1 file changed, 89 insertions(+)

>  create mode 100644 include/odp/api/spec/dev.h

>

> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

> new file mode 100644

> index 0000000..76d861a

> --- /dev/null

> +++ b/include/odp/api/spec/dev.h

> @@ -0,0 +1,89 @@

> +/* Copyright (c) 2016, Linaro Limited

> + * All rights reserved.

> + *

> + * SPDX-License-Identifier:     BSD-3-Clause

> + */

> +

> +/**

> + * @file

> + *

> + * ODP device

> + */

> +

> +#ifndef ODP_API_DEV_H_

> +#define ODP_API_DEV_H_

> +#include <odp/visibility_begin.h>

> +

> +#ifdef __cplusplus

> +extern "C" {

> +#endif

> +

> +#include <odp/api/std_types.h>

> +

> +/** @defgroup odp_dev ODP DEVICE

> + *  Operations on devices

> + *  @{

> + */

> +

> +/**

> + * @typedef odp_dev_t

> + * ODP Device

> + */

> +

> +/**

> + * @def ODP_DEV_NAME_LEN

> + * Maximum device name length in chars

> + */

> +

> +/**

> + * @def ODP_DEV_DEFAULT

> + * Default device

> + */

> +

> +/**

> + * @def ODP_DEV_INVALID

> + * Invalid device

> + */

> +

> +/**

> + * Get Device ID by Name

> + *

> + * Get an implementation-defined device identifier from a device name. Device

> + * names are supplied as parameter info (command line, file, etc.) to the

> + * application. This routine translates this symbolic name into an internal

> + * identifier that can be used to define a device connection hierarchy for

> + * NUMA or other purposes.

> + *

> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder

> + * wherever a device id is required.

> + *

> + * @param name Name of the device

> + *

> + * @return Device ID

> + * @retval ODP_DEV_INVALID Device is unknown

> + */

> +odp_dev_t odp_dev_id(const char *name);

> +

> +/**

> + * Get printable value for an odp_dev_t

> + *

> + * @param hdl  odp_dev_t handle to be printed

> + * @return     uint64_t value that can be used to print/display this

> + *             handle

> + *

> + * @note This routine is intended to be used for diagnostic purposes

> + * to enable applications to generate a printable value that represents

> + * an odp_dev_t handle.

> + */

> +uint64_t odp_dev_to_u64(odp_dev_t hdl);

> +

> +/**

> + * @}

> + */

> +

> +#ifdef __cplusplus

> +}

> +#endif

> +

> +#include <odp/visibility_end.h>

> +#endif

> --

> 2.7.4

>




 
-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

 
 



 
-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

 
 



 
-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

 



 
-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

 




-- 

François-Frédéric Ozog | Director Linaro Networking Group
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
Bill Fischofer Dec. 7, 2016, 12:26 p.m. | #14
I've included this topic in today's ARCH call.

On Wed, Dec 7, 2016 at 6:09 AM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolainen@nokia-bell-labs.com> wrote:
> DDF may be part of some implementations, but it's not compulsory. So, DFF must be able utilize dev API, but dev API does not depend on DDF. Dev API needs to provide freedom of implementation.

>

> Weather a device is behind PCI or not (or if SFP is used or not) is far beyond the API level. Application may ask to open "eth0" or "eth10g_backplane", which is the name of an Ethernet port on the blade (on the system). Implementation knows which driver to use for that interface (from system configuration, etc), application does not need to know about drivers or other implementation details of the interface.

>

> -Petri

>

>

> From: Francois Ozog [mailto:francois.ozog@linaro.org]

> Sent: Wednesday, December 07, 2016 1:34 PM

> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>

> Cc: Bill Fischofer <bill.fischofer@linaro.org>; lng-odp-forward <lng-odp@lists.linaro.org>; Christophe Milard <christophe.milard@linaro.org>

> Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

>

> Well, we need to formalize the scope and it looks like this is part of the Device and Driver Framework (DDF) that Christophe works on.

>

> I have asked Christophe to create a document complementing the patches it pushed so that we have a human readable reference on what the DDF does and the general mechanics of it.

>

> For instance the DDF can build a "physical" view of things through the various device enumerators (from DT to DPAA2 including ACPi, PCI, virtual, static...). But applications should not care about that. They may care of a "functional representation" derived from that hardware aspect. For instance controlling SFP aspects of a port may require controlling a specific PCI device ID while the port itself is under the control of another PCI device ID.

> Additional information can be found here: https://docs.google.com/a/linaro.org/presentation/d/1Ecb9-jA_7jbXtgMVImiTePzpOJsa6IldZMeFdjG8ypQ/edit?usp=sharing

>

> So until we know how (or even if) the proposed API fits in a functional framework (how it is used by what - application, odp internal, drivers only...) this is premature to introduce it.

>

> FF

>

>

> On 7 December 2016 at 12:13, Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com> wrote:

> I know device trees and how ugly those can be ….  values are not documented but you (your driver) just have to know what some list of four integers (reg = <4, 78865, 6, 565>) may actually mean…

>

> Anyway, the idea here is that

> •         an implementation has a way to enumerate resources to the user as names

> o   a name may come from a standard or system specific tool (ifconfig), a configuration file (even device trees), etc. API does not dictate how user gets a resource name, or which kind of string  that name is.

> •         User passes the name to the application (through command line, config file, env variable). API don’t dictate how that happens.

> •         Application passes the name to the implementation and gets a device ID (odp_dev_t), which it uses as a parameter on other calls

>

> Resource discovery/enumeration/management/etc is left to upper layer. API is only needed for passing resource identifier information down to the  implementation. And this is how it should be: ODP is a passive library which does what it’s told to do, the active role is on upper layers (user, scripts, resource management SW, etc entity).

>

> So, no need to defer the API since it’s flexible enough (to pass any kind of string down to implementation). Driver, cloud, etc frameworks may then specify the dev name string format, etc later on, but it would not change the API if a timer is called “timer0” or “timer0:2” or “/proc/soc/0/timer/1” or something else.

>

> -Petri

>

>

>

> From: Francois Ozog [mailto:francois.ozog@linaro.org]

> Sent: Tuesday, December 06, 2016 5:10 PM

> To: Bill Fischofer <bill.fischofer@linaro.org>

> Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri (Nokia - FI/Espoo) <petri.savolainen@nokia-bell-labs.com>; Christophe Milard <christophe.milard@linaro.org>

> Subject: Re: [lng-odp] [API-NEXT PATCHv3 1/3] api: dev: add device apis for numa support

>

> For the link, I think it ate the .... following it.

> Here it is without decoration:

> http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf

>

>

>

> On 6 December 2016 at 16:05, Francois Ozog <francois.ozog@linaro.org> wrote:

> OK. So let's defer the API but not the discussion.

> I think we need a "strategic architecture" call.

>

> FF

>

>

>

> On 6 December 2016 at 15:59, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> I have no problem deferring this if we want to have one of the SoC vendors drive a more comprehensive approach based on their capabilities which can then be generalized. BTW, your link doesn't resolve. Typo somewhere?

>

> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.ozog@linaro.org> wrote:

> Devicetree has been formed by and for SoC vendors to represent what they have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so it looks like very similar to what Petri is talking about.

>

> ACPI has also a concept of a proximity domains and the relative cost to use a resource from another domain.

>

> Handling NUMA requires a well thought through approach because it has implications at many levels in particular for device and driver framework.

>

> Bottom line, regardless if it's value, the introduction of the API seem too early as I haven't seen the use case that it supports and in particular the device and drivers framework.

>

> FF

>

>

>

>

>

>

> On 6 December 2016 at 14:23, Bill Fischofer <bill.fischofer@linaro.org> wrote:

>

>

> On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.ozog@linaro.org> wrote:

> Hi Bill,

>

> could you clarify if this "device" is related to devicetree as defined by Linaro (https://github.com/devicetree-org/devicetree-specification) or the devices that are in the scope of Christophe Millard, or some other device concept ?

>

> This is the Device ID proposal that Petri suggested at BKK16. It is not related to devtree or any other specific taxonomy as the idea was to establish an abstract "device" framework that would support both individual sockets or multi-SoC environments. In odp-linux these are basically placeholder functions as we don't have any cross-platform concept of NUMA. The idea is that each individual platform that does support NUMA should be able to map their native concepts into this framework to permit applications to associate an internal odp_dev_t handle with named devices.

>

>

> FF

>

>

>

> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> Ping. v3 of this patch is still awaiting review.

>

> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer

> <bill.fischofer@linaro.org> wrote:

>> Add the odp_dev_id() API used for NUMA support

>>

>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org>

>> ---

>> Changes for v3:

>> - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT

>>

>> Changes for v2:

>> - Incorporate changes suggested by Petri

>>

>>  include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++++++++++++++++++

>>  1 file changed, 89 insertions(+)

>>  create mode 100644 include/odp/api/spec/dev.h

>>

>> diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h

>> new file mode 100644

>> index 0000000..76d861a

>> --- /dev/null

>> +++ b/include/odp/api/spec/dev.h

>> @@ -0,0 +1,89 @@

>> +/* Copyright (c) 2016, Linaro Limited

>> + * All rights reserved.

>> + *

>> + * SPDX-License-Identifier:     BSD-3-Clause

>> + */

>> +

>> +/**

>> + * @file

>> + *

>> + * ODP device

>> + */

>> +

>> +#ifndef ODP_API_DEV_H_

>> +#define ODP_API_DEV_H_

>> +#include <odp/visibility_begin.h>

>> +

>> +#ifdef __cplusplus

>> +extern "C" {

>> +#endif

>> +

>> +#include <odp/api/std_types.h>

>> +

>> +/** @defgroup odp_dev ODP DEVICE

>> + *  Operations on devices

>> + *  @{

>> + */

>> +

>> +/**

>> + * @typedef odp_dev_t

>> + * ODP Device

>> + */

>> +

>> +/**

>> + * @def ODP_DEV_NAME_LEN

>> + * Maximum device name length in chars

>> + */

>> +

>> +/**

>> + * @def ODP_DEV_DEFAULT

>> + * Default device

>> + */

>> +

>> +/**

>> + * @def ODP_DEV_INVALID

>> + * Invalid device

>> + */

>> +

>> +/**

>> + * Get Device ID by Name

>> + *

>> + * Get an implementation-defined device identifier from a device name. Device

>> + * names are supplied as parameter info (command line, file, etc.) to the

>> + * application. This routine translates this symbolic name into an internal

>> + * identifier that can be used to define a device connection hierarchy for

>> + * NUMA or other purposes.

>> + *

>> + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder

>> + * wherever a device id is required.

>> + *

>> + * @param name Name of the device

>> + *

>> + * @return Device ID

>> + * @retval ODP_DEV_INVALID Device is unknown

>> + */

>> +odp_dev_t odp_dev_id(const char *name);

>> +

>> +/**

>> + * Get printable value for an odp_dev_t

>> + *

>> + * @param hdl  odp_dev_t handle to be printed

>> + * @return     uint64_t value that can be used to print/display this

>> + *             handle

>> + *

>> + * @note This routine is intended to be used for diagnostic purposes

>> + * to enable applications to generate a printable value that represents

>> + * an odp_dev_t handle.

>> + */

>> +uint64_t odp_dev_to_u64(odp_dev_t hdl);

>> +

>> +/**

>> + * @}

>> + */

>> +

>> +#ifdef __cplusplus

>> +}

>> +#endif

>> +

>> +#include <odp/visibility_end.h>

>> +#endif

>> --

>> 2.7.4

>>

>

>

>

>

> --

>

> François-Frédéric Ozog | Director Linaro Networking Group

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

>

> --

>

> François-Frédéric Ozog | Director Linaro Networking Group

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

>

> --

>

> François-Frédéric Ozog | Director Linaro Networking Group

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

> --

>

> François-Frédéric Ozog | Director Linaro Networking Group

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

>

>

>

>

> --

>

> François-Frédéric Ozog | Director Linaro Networking Group

> T: +33.67221.6485

> francois.ozog@linaro.org | Skype: ffozog

>

>

Patch

diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h
new file mode 100644
index 0000000..76d861a
--- /dev/null
+++ b/include/odp/api/spec/dev.h
@@ -0,0 +1,89 @@ 
+/* Copyright (c) 2016, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:     BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP device
+ */
+
+#ifndef ODP_API_DEV_H_
+#define ODP_API_DEV_H_
+#include <odp/visibility_begin.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <odp/api/std_types.h>
+
+/** @defgroup odp_dev ODP DEVICE
+ *  Operations on devices
+ *  @{
+ */
+
+/**
+ * @typedef odp_dev_t
+ * ODP Device
+ */
+
+/**
+ * @def ODP_DEV_NAME_LEN
+ * Maximum device name length in chars
+ */
+
+/**
+ * @def ODP_DEV_DEFAULT
+ * Default device
+ */
+
+/**
+ * @def ODP_DEV_INVALID
+ * Invalid device
+ */
+
+/**
+ * Get Device ID by Name
+ *
+ * Get an implementation-defined device identifier from a device name. Device
+ * names are supplied as parameter info (command line, file, etc.) to the
+ * application. This routine translates this symbolic name into an internal
+ * identifier that can be used to define a device connection hierarchy for
+ * NUMA or other purposes.
+ *
+ * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" placeholder
+ * wherever a device id is required.
+ *
+ * @param name Name of the device
+ *
+ * @return Device ID
+ * @retval ODP_DEV_INVALID Device is unknown
+ */
+odp_dev_t odp_dev_id(const char *name);
+
+/**
+ * Get printable value for an odp_dev_t
+ *
+ * @param hdl  odp_dev_t handle to be printed
+ * @return     uint64_t value that can be used to print/display this
+ *             handle
+ *
+ * @note This routine is intended to be used for diagnostic purposes
+ * to enable applications to generate a printable value that represents
+ * an odp_dev_t handle.
+ */
+uint64_t odp_dev_to_u64(odp_dev_t hdl);
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#include <odp/visibility_end.h>
+#endif