Rick Jones <[EMAIL PROTECTED]> writes: > > Still, does this look like something worth persuing? In a past > life/OS when one was able to eliminate one percentage point of > spinlock contention, two percentage points of improvement ensued.
The stack is really designed to go fast with per CPU local RX processing of packets. This normally works because waking on up a task the scheduler tries to move it to that CPU. Since the wakeups are on the CPU that process the incoming packets it should usually end up correctly. The trouble is when your NICs are so fast that a single CPU can't keep up, or when you have programs that process many different sockets from a single thread. The fast NIC case will be eventually fixed by adding proper support for MSI-X and connection hashing. Then the NIC can fan out to multiple interrupts and use multiple CPUs to process the incoming packets. Then there is the case of a single process having many sockets from different NICs This will be of course somewhat slower because there will be cross CPU traffic. However there should be not much socket lock contention because a process handling many sockets will be hopefully unlikely to bang on each of its many sockets at the exactly same time as the stack receives RX packets. This should also eliminate the spinlock contenion. >From that theory your test sounds somewhat unrealistic to me. Do you have any evidence you're modelling a real world scenario here? I somehow doubt it. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
