From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 21 10:43:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 892FD37B401 for ; Mon, 21 Apr 2003 10:43:14 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 019D843FA3 for ; Mon, 21 Apr 2003 10:43:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0061.cvx22-bradley.dialup.earthlink.net ([209.179.198.61] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197fJs-0006WF-00; Mon, 21 Apr 2003 10:43:09 -0700 Message-ID: <3EA42D52.71BE3533@mindspring.com> Date: Mon, 21 Apr 2003 10:41:38 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dirk-Willem van Gulik References: <20030421130029.A29555-100000@foem.leiden.webweaving.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4632424668222e73f49001c07c5b24410a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: DEVICE_POLLING (was Re: wi(4) - polling(4) changes / DEVICE_POLLING) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:43:14 -0000 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