Paul Durrant wrote: > Wesley Shao wrote: >> >> So in the world of windows, does the OS provide driver the information >> on how many CPUs you have in the system, and the relationships among >> the cores and strands (sharing L1 or L2 cache, etc)? > > Nope. All you've got is the number of CPUs; we have to do intrinsic > CPUID calls to get package/core/thread info. and infer cache info. from > that. At least we can get this info. on Solaris without having to resort > to intrinsics.
I would prefer this information be presented in an architected manner so it would work for both SPARC and x86 platforms and move the package/core/thread determination out of the driver and into kernel, wouldn't you agree? BTW, do you care about SPARC platform for this particular device? >> The "policy setting" you mentioned above, did you mean some policies >> the OS already support and driver picks one of them or do you mean >> the driver comes up with its own set of policies and select one based >> on the cpu information? >> > > Windows supports several interrupt distribution policies. See > http://msdn2.microsoft.com/en-us/library/aa491499.aspx > >> If I am not mistaken, you are hoping the OS can provide cpu information. >> Can you be a little more specific on what type of info your driver >> would require, in order to make intelligent traffic routing decisions? >> > > Usually you don't really want multiple threads contending for whatever > the bottleneck in the system is. In most cases with current Intel > chipsets this is the L2 cache or the front-side bus. You therefore want > information about how the CPUs in the system are laid out so that the > driver can decide which of the set of MSI-X interrupts it has bound to > those various CPUs it actually wants to use so as not to end up with > pointless resource contention. Usually it is only the driver which has > the knowledge of what the data-flow will be so really it is only the > driver that can make such a decision. I would argue that one driver instance cannot know the load on all system cpus, so some other entity with a global view of interrupt allocation would be better off to make the interrupt distribution decision. Would you object to some userland management entity? It might require device drivers to provide some ioctl implementation. > The best solution from my point of view would be a call to get me N > interrupts (which already exists in Solaris, acpi_msix_max and > ddi_msix_alloc_limit having been hacked) and then a call to bind each of > those interrupts to a specific CPU once the driver has worked out which > CPUs would be optimal. This call, as far as I know, does not exist so we > have to over-allocate interrupts using another hack to set the > apic_intr_policy and then cherry-pick the subset that will cause the > least resource contention. > > Paul Thanks and your comments are greatly appreciated, Wes _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
