| Message ID | 1477344567-2561-1-git-send-email-bill.fischofer@linaro.org |
|---|---|
| State | New |
| Headers | show |
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 >
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
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 > >
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 >> >> >
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
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 > >
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
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
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
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
... 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
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
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
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 > >
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
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