Wesley Shao wrote: >Paul Durrant wrote: > > >>Wesley Shao wrote: >> >> >>>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. > > > The driver does know something, e.g. how the interrupts will access the data. Sometimes you want to spread the interrupts far away to avoid contending for the cache, while other times you may just want them to share same cache. It all depends on what kind of data will be accessed and only the driver knows that. On NUMA you want the interrupt to be serviced by the CPU nearest to the data.
So it would be nice if the driver can at least convey an attribute like processor affinity or lgroup binding to the kernel when the interrupts are allocated. The kernel makes the final decision on scheduling but the driver can express the desired policy for an interrupt. >Would you object to some userland management entity? It might require >device drivers to provide some ioctl implementation. > > > This would be interesting but what can you tell the driver via the ioctl? Vincent. _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
