On Thu, 2017-02-16 at 23:17 +0200, Saeed Mahameed wrote: > so i guess you are not busy polling .. and adaptive moderation decided > to lower down > rx-usecs for you, and you are looking to improve latency. > > > Interrupt moderation is a latency killer, we want our usec back. > > > > well, for RX we have adaptive moderation. > and for TX we have xmit more. > so interrupt moderation can be good if it is done right. > > do i understand from this that you are against interrupt moderation ?
Absolutely against it. We prefer gro_flush_timeout. The defaults values in mlx4 never were tuned for 40Gbit. If you want to be able to reach 40Gbit on a single TCP flow, you want : ethtool -C ethX rx-frames 16 rx-usecs-high 32 Or disable interrupt mitigation of course. Interrupt moderation comes for free with NAPI really : If under stress, number of interrupts will naturally decrease, so what's the point with hardware _delaying_ an incoming packet exactly ??? BTW interrupt moderation in mlx4 has at least two bugs. I will send a patch. > > >> > >> > I wonder why this very expensive mb() is required, right before exiting > >> > the interrupt handler. > >> > >> to make sure the HW knows we handled Completions up to (ci) consumer > >> index. so it will generate next irq. > > > > > > So why a mb() is needed exactly ? > > > > wmb() seems enough. > > > > Yes seems right, not sure why it is mb() though, i will have to check > and get back to you on this. Thanks.
