On 13 October 2016 at 14:06, Bill Fischofer <bill.fischo...@linaro.org> wrote:
>
>
> On Thu, Oct 13, 2016 at 6:53 AM, Christophe Milard
> <christophe.mil...@linaro.org> wrote:
>>
>> On 13 October 2016 at 13:44, Bill Fischofer <bill.fischo...@linaro.org>
>> wrote:
>> >
>> >
>> > 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.
>>
>> hmmm interesting... not very clear to me what would be the difference
>> between a handle and a dev. If handles can be references to anything,
>> I don't really see why we wouldn't keep using handles for these
>> things. And I am not sure either having a name as "dev" to cover
>> everything makes it clear.
>> Thanks for answering anyway :-) maybe it will become clearer in the
>> future.
>>
> I'll add this to Monday's ARCH call so Petri can explain it in more detail
> :)

Thanks!

Christophe
>
>
>>
>> >
>> >>
>> >>
>> >> 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