On Thu, Oct 13, 2016 at 6:33 AM, Christophe Milard < [email protected]> wrote:
> On 13 October 2016 at 13:20, Bill Fischofer <[email protected]> > wrote: > > > > > > On Thu, Oct 13, 2016 at 2:03 AM, Christophe Milard > > <[email protected]> wrote: > >> > >> On 13 October 2016 at 02:44, Bill Fischofer <[email protected]> > >> wrote: > >> > Add the odp_dev_id() API used for NUMA support > >> > > >> > >> I am a bit confused here: what is a device? a numa_id or other things > >> as well? In this patch series everything that relates to numa is > >> called "device". Shouldn't be called numa_dev when it is a numa > >> device? > >> If devices are numa dev only, they should be called numa_dev. If a > >> device can be anything else (which you general approach seems to > >> imply), how are they different from handles? > >> > >> Not sure I understand where these patches lead to... > > > > > > These patches are just implementing the APIs proposed by Petri during the > > ODP Design Summit at LAS16. We can consider them RFCs for now if that's > > preferable. A dev_id in ODP is supposed to be the same as a socket_id in > > DPDK, but not necessarily tied to the CPU socket config. The intent is > > simply to have a placeholder where hierarchical NUMA-type identifiers > can be > > obtained and then used as part of resource (pools, etc.) creation. This > is > > inherently system dependent, which is why the odp-linux versions are > mostly > > placeholders, and why I put the implementations under the arch directory. > > > > But still: is this for numa only (in which case I would expect a > clearer name) or are these devices meant to be used by other things > (which ones?). And how does this differ from the handles we already > have for other objects? > It's not necessarily NUMA since the intent is to be able to cover multi-SoC configurations as well. A dev_id differs from a handle because it's a qualifier. So, for example, an odp_pool_t is the ODP handle for a pool, however the pool may have a couple of dev_id qualifiers that are used as part of it's creation (Petri identified pool_id and dram_id as two). Similarly a crypto_session uses a dev_id to identify a specific crypto resource bound to that session. For example a system might have four crypto engines that have different "distance" depending on where the thread is running and the dev_id would distinguish those. > > Christophe > >> > >> > >> Christophe. > >> > >> > Signed-off-by: Bill Fischofer <[email protected]> > >> > --- > >> > 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..1f7ed8b > >> > --- /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_ANY > >> > + * Any 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_ANY 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 > >> > > > > > >
