On 5/26/2014 3:39 PM, Thomas Gleixner wrote: [...]
The rmap _IS_ instantiated by the driver, and both the driver and the networking core know about it. So it's not completely different consumers. Just because it's a library does not mean it's disjunct from the code which uses it. Aside of the fact, that maintaining a per irq notifier chain is going to be ugly as hell due to life time and locking issues, it's just opening a can of worms. How do you make sure that the invocation order is correct? What are the dependency rules of the driver restarting the napi session versus updating the rmap? Even if you'd solve that and have a callback in the driver, then the callback never can restart the napi session directly. All it can do is set a flag which needs to be checked in the RX path, right? So what's the point of adding notifier call chain complexity, ordering problems etc., if you can simply note the fact that the affinity changed in the rmap itself and check that in the RX path?
I will try to find a solution in the spirit of what you suggested - to let the rmap library notify napi about affinity changes - without adding this complexity to the code.
Thanks, Amir
Thanks, tglx
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/