Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled

[Hooman Fazaeli]

On 11/10/2011 3:39 AM, Adrian Chadd wrote:
> There's no locking around the OACTIVE flag set/clear, right?
> Is it possible that multiple TX threads are fiddling with OACTIVE and
> then it's not being properly cleared and tx kicked?
>
>
> Adrian
If we check for OACTIVE periodically (for instance, in local_timer) and under
transient resource shortage, the driver will finally end up with OACTIVE
cleared. Under frequent resource shortages, the driver may remain OACTIVE
longer than it is ~OACTIVE or it may constantly toggles but there is
not much the driver can do about this and a simple locking around OACTIVE set/clear
does not change the situation. The problem _is_ low resources and the only
fix is to increase it.

The problems we should focus on here are two things:

1- The driver _must_ be able to recover from OACTIVE after transient resource shortages.
2- It is desirable to do this as fast as possible.

Doing recovery in local_timer accommodates the first need but it is very far from
from the second.

One possible solution for 2 would be to defer setting OACTIVE until N consecutive
transmissions fail (i.e., N == 75% (if_snd.ifq_maxlen - if_snd.ifq_len)). The overhead
is a little wasted cpu time in longer OACTIVE states. We still need local_timer
to recover from these states.