Grant Grundler wrote:
Wellll..Looks like I'm wrong. Previous email on this thread suggested it's possible by people who know alot more about it than I do. But I'm still concerned it's going to affect latency.
Maybe that's one reason why NAPI was made a compile time option? Anyway, it might be just as easy to implement IB netdev->poll() also as a compile time option.
Isn't that what the midas touch of netdev->poll() really is? e1000 has: quit_polling: netif_rx_complete(netdev); e1000_irq_enable(adapter);
I'm more familiar with tg3 driver. The disadvantage to NAPI in the tg3 implementation is it *alays* disables interrupts on the card before calling netif_rx_schedule(). Then it lets the OS decide when to actually process those packets *already* received in a safer context....then once tg3 decides it's done all the work it re-eables the interrupts. Just like e1000 does above.
There are some workloads where the PCI bus utilization is "suboptimal" because the enable/disable of interrupts interfers with the DMA flows and costs excessive overhead.
Maybe. I'm not a PCI expert and have only used a PCI bus analyzer a few times. I don't understand how disabling the interrupts would interfere with DMA or add overhead. That condition strikes me as being chip dependent. So, perhaps the tg3 does that, but an IB HCA would be different. (?)
Jeff _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
