"Leonid Grossman" <[EMAIL PROTECTED]> writes: > There two facilities (at least, in our ASIC, but there is no reason this > can't be part of the generic multi-channel driver interface that I will > get to shortly) to deal with it. > > - hardware supports more than one utilization-based interrupt rate (we > have four). For lowest utilization range, we always set interrupt rate > to one interrupt for every rx packet - exactly for the latency reasons > that you are bringing up. Also, cpu is not busy anyways so extra > interrupts do not hurt much. For highest utilization range, we set the > rate by default to something like an interrupt per 128 packets. There is > also timer-based interrupt, as a last resort option. > As I mentioned earlier, it would be cool to get these moderation > tresholds from NAPI, since it can make a better guess about the overall > system utilization than the driver can. But even at the driver level, > this works reasonably well. > > - the moderation scheme is implemented in the ASIC on per channel basis. > So, if you have workloads with very distinct latency needs, you can just > steer it to a separate channel and have an interrupt moderation that is > different from other flows, for example keep an interrupt per packet > always.
How do you classify channels? If your channels can map directly to the VAN Jacobsen channels then when the kernel starts using them, it sounds like the ideal strategy is to use the current NAPI algorithm of disabling interrupts (on a per channel basis (assuming MSI-X here) until that channel gets caught up Then enable interrupts again. I wonder if someone could make that the default policy in their NICs? Eric - 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
