Garrett D'Amore 写道:
Why not deal with them under the interrupt? Assuming you can process
them all in the same interrupt context (i.e. you do not want to have
to service multiple interrupts, but once you're already in interrupt
context, if the packets keep coming, there is no real reason not to
deal with them there, as long as you can do so quickly, without tying
up the CPU from processing other system critical tasks. In multi-CPU
systems, the idea of dedicating an processor to handing rx interrupts
from a high-traffic NIC is actually very reasonable.)
To a certain extent, the question of the "context" that you are
handling the traffic in is one of resource allocation... interrupt
context is a bad place for a shared CPU to be, at least for very long.
But if you have the CPU to dedicate to the job, and the traffic to
justify it, leaving the CPU running in interrupt context works pretty
well.
In fact, lately I've been doing a lot of performance testing with IP
forwarding of very small (64-byte) packets. I've found that the best
way to get good performance on systems with multiple CPUs is to
allocate a CPU to the task of interrupt handling for each high-traffic
NIC. Right now this requires some finagling with psrset and psradm -i,
and looking at bindings with mdb "::interrupts", but it is really
worthwhile. The performance boost you get by doing this kind of
tweaking can be nearly 100%.
Hi Garrett,
Would you please show the steps in detail on making this? We are very
interested in this.
Thanks,
Jason
(E.g. I've been able to process ~500,000 inbound packets per second on
a single 2.4GHz core using this technique. I'm looking at ways to
increase this number even further.)
_______________________________________________
networking-discuss mailing list
[email protected]
