On Thu, Oct 13, 2016 at 6:33 AM, Christophe Milard <
christophe.mil...@linaro.org> wrote:

> On 13 October 2016 at 13:20, Bill Fischofer <bill.fischo...@linaro.org>
> wrote:
> >
> >
> > On Thu, Oct 13, 2016 at 2:03 AM, Christophe Milard
> > <christophe.mil...@linaro.org> wrote:
> >>
> >> On 13 October 2016 at 02:44, Bill Fischofer <bill.fischo...@linaro.org>
> >> 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 <bill.fischo...@linaro.org>
> >> > ---
> >> >  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
> >> >
> >
> >
>

Reply via email to