Jeff Squyres wrote:
> On Apr 24, 2007, at 2:31 PM, Bert Wesarg wrote:
>
>>>> - have node ID, want a list of processor IDs and/or a list of
>>>> (socket,core) tuples
>>>> plpa_map_from_node(int node_id, int *socket, int *core, int
>>>> *processor_id);
>>>> (socket,core) can be NULL or processor_id can be NULL, but not
>>>> both.
>>> how about this:
>>>
>>> /* return a cpumap with all processor ids in node node_id */
>>> plpa_map_from_node(int node_id, plpa_cpu_set_t *processorset);
>
> 1. Were you silently agreeing with the other 2 functions
> (map_from_socket_core and map_from_procesor)?
Not really, IMO these two mappings are sufficient to expose it directly to
the user:
(1) one-to-one: (socket,core) <-> processor ID
(2a) one-to-one: processor ID -> node ID
(2b) one-to-many: node ID -> processor ID
>
> 2. Is the rationale of your new function a desire to unify the data
> into a single data structure (vs. 3 int arrays)?
No, only to provide a function for the (2b) mapping
>
>> To make this a little user friendly, I think it is needed to extend
>> the
>> plpa_cpu_set_t API with functions like:
>>
>> * copy
>> * count set bits
>
> These 2 sound good.
>
>> * simple iterator over all set bits
>
> What do you suggest this would look like?
the linux kernel has a macro like:
forall_cpus(cpu, *cpumask)
which expends to a for loop, and cpu takes all values for which
CPU_ISSET(cpu, cpumask) is true
>
>> * find next set/unset?
>
> This can be done -- but is it useful? Or is it syntactic sugar
> around the iterator interface?
infact, the iterator would be syntactic sugar for these kind of function
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}