From owner-freebsd-net@FreeBSD.ORG Sun Feb 5 18:09:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CED1A16A420 for ; Sun, 5 Feb 2006 18:09:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8452C43D46 for ; Sun, 5 Feb 2006 18:09:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id k15I9Yo7044680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Feb 2006 10:09:35 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43E63FC3.2030409@errno.com> Date: Sun, 05 Feb 2006 10:11:15 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051227) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nielsen@memberwebs.com References: <20060205011931.E5F08DCA99E@mail.npubs.com> In-Reply-To: <20060205011931.E5F08DCA99E@mail.npubs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" Subject: Re: Polling for ath driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2006 18:09:35 -0000 Nate Nielsen wrote: > I've been working on polling for the FreeBSD ath wireless driver. > > On slow CPU's polling helps prevent (by supressing certain interrupts) > livelock and increases throughput. This is true of Atheros cards on > Soekris and other embedded hardware. > > Just thought I'd post something here in case anyone is interested in > helping with insight, code or testing. I've got a rough (and mostly > working) patch. There are some locking issues to contend with... You might try explaining why you think polling helps your performance. Unless you've significantly restructured the interrupt handling in the driver most work is deferred to a non-interrupt context. Also the driver in 6.0 and later does tx interrupt mitigation and rx interrupt coalescing so I wouldn't expect interrupt handling to be a performance limitation. There are other issues that can affect performance but you haven't mentioned them... Sam