On Tue, Feb 2, 2016 at 5:41 AM, Savolainen, Petri (Nokia - FI/Espoo)
<[email protected]> wrote:
>
>
...
>> + This cpumask is used only to convey externally supplied
>> + ODP instance during initialization. Applications code must call
>> + odp_cpumask_default_worker() to obtain information as to the
>
> Since the function above returns the default mask for workers, the call makes
> sense (only) when user wants to use default settings of the implementation.
> So,
> the "must" above should be "may". When user does not know or care which CPUs
> to use
> it can pass NULL here and call default_worker().
>
My intent was to indicate that the cpumask should never be referenced
directly from an application - but rather that this information should
only be obtained via the above function call. However, I see this
line can be misinterpreted - so less ambiguously perhaps it should
say:
Applications code wishing to obtain information as to the
CPU resources available for worker threads must call
odp_cpumask_default_worker() and should never
reference this cpumask directly.
> If user passes a bad CPU mask (a bad range of CPUs), the global init should
> fail.
I did not want to specify this in the API. Determining what
constitutes a valid range of CPUs may be a complex issue - so I wanted
to leave the handling of that to the implementation developer rather
than mandating it in the API spec.
In fact, my proposed helper code takes the user's passed-in CPU masks
and sanitizes them based on a number of factors including the
underlying CPU topology and the kernel's internal handling of CPU
resources... details which I think the application writer shouldn't
be burdened with. The passed-in CPU masks are used as 'boundaries'
(with the exception of overrides regarding CPU 0) and any invalid
contents are cleaned up prior to calling odp_init_global().
Whether it is preferred simply to abort on bad cpumask input or to
clean them up, possibly emit diagnostic error messages, and continue
as best as possible is a debatable policy issue which I hoped to
address with patches not yet submitted.
I had hoped to confine this patch to simply include the API extension
adding the ability to pass externally specified cpumasks and to
address what should be done with those cpumasks in other patch
submissions.
Thanks for your attention and inputs. If you will let me know whether
it is acceptable not to specify bad CPU mask input handling in the API
documentation, then I will modify the comments as needed and resubmit.
...
>> + This cpumask is used only to convey externally supplied
>> + information regarding control CPU resources available to this
>> + ODP instance during initialization. Applications code must call
>
> Same here.
Applications code wishing to obtain information as to the
CPU resources available for control threads must call
odp_cpumask_default_control() and should never
reference this cpumask directly .
>
> -Petri
>
>
>> + odp_cpumask_default_control() to obtain information as to the
>> + CPU resources available for control threads. */
>> + odp_cpumask_t *control_cpus;
>> /** Replacement for the default log fn */
>> odp_log_func_t log_fn;
>> /** Replacement for the default abort fn */
>> --
>> 1.9.1
>
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
