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.savolai...@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.o...@linaro.org] > Sent: Wednesday, December 07, 2016 1:34 PM > To: Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> > Cc: Bill Fischofer <bill.fischo...@linaro.org>; lng-odp-forward > <lng-odp@lists.linaro.org>; Christophe Milard <christophe.mil...@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.savolai...@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.o...@linaro.org] > Sent: Tuesday, December 06, 2016 5:10 PM > To: Bill Fischofer <bill.fischo...@linaro.org> > Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Savolainen, Petri (Nokia - > FI/Espoo) <petri.savolai...@nokia-bell-labs.com>; Christophe Milard > <christophe.mil...@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.o...@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.fischo...@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.o...@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.fischo...@linaro.org> wrote: > > > On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.o...@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.fischo...@linaro.org> wrote: > Ping. v3 of this patch is still awaiting review. > > On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer > <bill.fischo...@linaro.org> wrote: >> Add the odp_dev_id() API used for NUMA support >> >> Signed-off-by: Bill Fischofer <bill.fischo...@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.o...@linaro.org | Skype: ffozog > > > > > > > > -- > > François-Frédéric Ozog | Director Linaro Networking Group > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > > -- > > François-Frédéric Ozog | Director Linaro Networking Group > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > -- > > François-Frédéric Ozog | Director Linaro Networking Group > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > > > > > -- > > François-Frédéric Ozog | Director Linaro Networking Group > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > >
