Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-10 Thread Brice Goglin
Jeff Squyres wrote: >> and Jeff has already removed the PLPA tests from >> trunk, I am going to add (1) and probably (3), and document (2) and (4) >> in the PLPA doc section. Then I'll move most comments from plpa.h into >> this doc section and remove plpa.h entirely. >> > > How about having

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-10 Thread Jeff Squyres
On Dec 10, 2009, at 5:22 PM, Samuel Thibault wrote: > > Are you saying that the API will be all OS/physical, with conversion > > functions from #3 to convert to/from logical? > > No, it should stay logical, conversion would be just to translate into > OS/physical. Ok -- good. Consistent (CLI

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-02 Thread Brice Goglin
Brice Goglin wrote: > Jeff Squyres wrote: > >> FWIW, having a "simple" API like that might be a Good Thing...? >> >> I.e., just be able to bind to a specific thread/core/socket with a >> minimum fuss/muss. Even if such an API would be mainly syntactic sugar >> for other hwloc functionality --

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: >> Well, the list of good ideas will be very short then :) Most remaining >> functions are about manipulating core and socket ids, we don't need that >> at all in hwloc anymore. > > FWIW, having a "simple" API like that might be a Good Thing...? > > I.e., just be able to bind

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Samuel Thibault
Jeff Squyres, le Thu 12 Nov 2009 10:05:32 -0800, a écrit : > apps that run on specific servers for specific purposes, where the > developers hard code in there "bind to cores 1-4" or "bind to sockets > 1,3" because they already know the setup and this app is not intended > to be portable.

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Jeff Squyres
On Nov 12, 2009, at 9:56 AM, Brice Goglin wrote: Well, the list of good ideas will be very short then :) Most remaining functions are about manipulating core and socket ids, we don't need that at all in hwloc anymore. My feeling is that converting an application from PLPA's

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: > Sorry for the delay in replying to this; been caught up in SC09 prep... Next time, I'll commit immediately instead of waiting for a week in case somebody ever reads my emails :) Brice

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: > On Nov 12, 2009, at 9:25 AM, Samuel Thibault wrote: > >> > > There's certainly some desirable PLPA API features that could be >> > > imported to the HWLOC API -- but I would think that if people >> want to >> > > keep using the PLPA API, they can. It just won't [ever] be

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Samuel Thibault
Brice Goglin, le Thu 12 Nov 2009 18:13:34 +0100, a écrit : > Jeff Squyres wrote: > >> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new > >> hwloc_topology_t parameter. The problematic ones are: > >> > >> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset);

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: >> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new >> hwloc_topology_t parameter. The problematic ones are: >> >> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset); >> > > Hmm. I'm a little confused. If we don't provide a drop-in

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Jeff Squyres
Sorry for the delay in replying to this; been caught up in SC09 prep... On Nov 5, 2009, at 8:22 AM, Brice Goglin wrote: * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new hwloc_topology_t parameter. The problematic ones are: + int hwloc_plpa_sched_getaffinity(pid_t

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-11 Thread Samuel Thibault
Brice Goglin, le Mon 09 Nov 2009 15:18:11 +0100, a écrit : > I don't think we need SET_CPUBIND since (from what I understand) it > would be equivalent to SET_PROC_CPUBIND | SET_THREAD_CPUBIND. Being able to set oneself's cpuset is not the same as being able to set the cpuset of other processes or

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-11 Thread Samuel Thibault
Brice Goglin, le Thu 05 Nov 2009 17:22:15 +0100, a écrit : > + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset); > > It's just a hwloc_get_cpubind(), but we don't have it since it would not > be supported on all OS. But I think we should add it anyway. Being discussed in

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-09 Thread Brice Goglin
Brice Goglin wrote: > * Probing > > >From what I understand, plpa_have_topology_information() tells whether > PLPA knows what's in the hardware, while plpa_api_probe() tells whether > binding is supported. We could add: > > + hwloc_topology_support(hwloc_topology_t topology, unsigned *support) >

[hwloc-devel] towards PLPA-like API in 1.0

2009-11-05 Thread Brice Goglin
Hello, I've been looking at the PLPA API and here's what we could do to add a hwloc/plpa.h offering kind of the same features. * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new hwloc_topology_t parameter. The problematic ones are: + int