DEVICE_POLLING (was Re: wi(4) - polling(4) changes / DEVICE_POLLING)

[Terry Lambert]

Dirk-Willem van Gulik wrote:
> Is anyone actively working on making the polling(8) to the wi(4) driver ?
> 
> As in www.wirelessleiden.nl we're seeing very significant (>80%) INTR
> time spend when doing simple bridging from one wi(4) card to another on
> the lower end motherboards (P1, slow P2's).
> 
> And we have similarly seen that using DEVICE_POLLING on the sis(4) cards
> in the same device would instantly drop sis0<->sis1 INTR time resources to
> acceptible levels (and increase performance by almost a 2 fold).
> 
> Or are there any fundamental issues with making wi(4) polling(4) aware ?
> I.e. some specific firmware issues, etc ?

It's highly card dependent.  I only have one very old card that
could not be converted to polling.  The reason is that DMA's do
not continue to occur to unused ring buffer elements once an
interrupt is posted, until that interrupt is acknowledged.

If the wi(4) card was too dumb, and did this, then it would have
the same problem, and require a firmware update.  I doubt this
is the case, so a conversion is probably no problem.

I did the polling conversion on a couple of the drivers; it was
very easy.

Having done this conversion, it seems to me that the driver code
should be refactored to add *_rxeof and *_txeof, as well as an
*_interrupt_able and *_interrupt_pending entry points to the
device_method_t array (for this last, see if_sis.c).  The entry
point *_interrupt_able would enable and disable interrupts, based
on its argument.

This means there are a couple of drivers that need to be changed
to refactor them to look more like Bill Paul's drivers.

If this is done, and the polling loop code was made higher-level
in common code, rather than being placed in each and every driver,
then all future drivers would be "polling safe", automatically.

We could also move soft interrupt coelescing to upper level code,
as well (for the non-DEVICE_POLLING case).

-- Terry