Date: Mon, 21 Apr 2003 10:41:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dirk-Willem van Gulik <dirkx@webweaving.org> Cc: freebsd-hackers@freebsd.org Subject: DEVICE_POLLING (was Re: wi(4) - polling(4) changes / DEVICE_POLLING) Message-ID: <3EA42D52.71BE3533@mindspring.com> References: <20030421130029.A29555-100000@foem.leiden.webweaving.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA42D52.71BE3533>