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 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 -- there definitely is something to be > said for "make the simple things simple". It will definitely (IMNSHO) > extend hwloc's reach into a larger class of applications. Meaning: > there are a variety of hard-coded apps out there that we'll never see; > 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.
Oh sorry, I wasn't clear. I am not against a socket+core API [1]. What I find useless with hwloc is using the physical/OS ids. hwloc/plpa.h uses obj->os_index everywhere, while os_index is meaningless excep at the PROC level (when binding). If you want the second core in the second socket, you don't care about their physical/OS indexes (which are often non-consecutive, repeating, ...), you just want to use logical indexes. OS/physical indexes change all the time anyway (when upgrading the BIOS, the kernel, ...). > It may be useful to have the API be extensible; I don't see how you could be extensible without being close the generic hwloc API. > one thing I have heard rumors about coming in the not-distant future > is the concept of "boards" (multiple motherboards in a single box). > I.e., socket IDs may be repeated; they are differentiated by board > number. Actually, we've seen many strange things like this in the non-x86 world. It doesn't look very different from Bull's QBBs or SGI Blades in large Itanium machines :) Brice [1] But we'll have to choose between socket+core and NUMA+core (often similar but not always), and maybe other useful basic setups.
