jason jiang writes: > >From my experience, use the softintr to distribute the packets to > upper layer will get poor performance on latency and througput > performance than handle it in single interrupt thread. And you want to > make sure do not handle too much packets in one interrupts. > > > This message posted from opensolaris.org > _______________________________________________ > networking-discuss mailing list > [email protected]
I see that both interrupt scheme suffer from the same drawback of pinning whatever thread happens to be running on the interrupt/softintr cpu. The problem gets really annoying when the incoming inter-packets time interval is smaller than the handling time under the interrupt. Even if the code is set to return after handling N packets, a new interrupt will be _immediately_ signified and the pinning will keep on going. Now, the per-packet handling time, is not a well defined entity. The software stack can choose to do more (say push up through TCP/IP) or less work (just queue and wake kernel thread) on each packet. All this needs to be managed based on the load and we're moving in that direction. At the driver level, if you reach a point where you have a large queue in the HW receive rings, that is a nice indication that deferring the processing to a non-interrupt kernel thread would be good. Under this condition the thread wakeup cost is amortized over the handling of many packets. -r _______________________________________________ networking-discuss mailing list [email protected]
