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.
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. 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
begin:vcard fn:Paul Durrant n:Durrant;Paul email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE url:http://www.linkedin.com/in/pdurrant version:2.1 end:vcard
_______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
