The main idea behind TOPS and prior to that IPS was to spread-out
the processing of packets across as many CPUs as we could, as "correctly" as we
could.
Very very hard to do.
Why do you say that? "Correct" can be defined as either the same CPU for each
packet in a given flow (IPS) or the same CPU as last accessed the endpoint (TOPS).
Isnt MSI supposed to give you ability such that a
NIC can pick a CPU to interupt? That would help in a small way
That gives the NIC the knowledge of how to direct to a CPU, but as you know does
not tell it how to decide where. Since I doubt that the NIC wants to reach-out
and touch connection state in the host (nor I suppose do we want it to either)
the best a NIC with MSI could do would be IPS
TOPS lets the process (I suppose the scheduler really) decide where some of the
processing for the packet will happen - the part after the handoff.
I think this last part should be easy to do - but perhaps the expense of
landing on the wrong CPU may override any benefits perceived.
Unless one has a scheduler that likes to migrate processes, the chances of
landing on the wrong CPU are minimal and shortlived, and overall, the chances of
being right are greater than if not doing anything and sticking with the
interrupt CPU. (Handwaving based on experience-driven intuition and a bit of
math as one increases the CPU count) This is all on the premis that one is
running with numNIC << numCPU. With numNIC == numCPU one does things as seen in
certain networking-intensive benchmarks :)
rick jones
|