From owner-freebsd-hackers Wed Nov 20 10:18:49 2002 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 7D9C537B401 for ; Wed, 20 Nov 2002 10:18:47 -0800 (PST) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C11D43E8A for ; Wed, 20 Nov 2002 10:18:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0223.cvx21-bradley.dialup.earthlink.net ([209.179.192.223] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18EZQq-0003nQ-00; Wed, 20 Nov 2002 10:18:36 -0800 Message-ID: <3DDBD199.4FB8FDA0@mindspring.com> Date: Wed, 20 Nov 2002 10:16:57 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Bowman Cc: hiten@unixdaemons.com, tony@ubik.demon.co.uk, freebsd-hackers@freebsd.org Subject: Re: if_ti DEVICE_POLLING patch (Was: Re: [hackers] Re: Netgraphcouldbe a router also) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Don Bowman wrote: > Is there any point to using device polling with the tigon 3 > (broadcom 570x etc)? It has a pretty good interrupt reducer in it > by itself. > Just tune the 2 rx and the 2 tx parameters and you get a constant > interrupt rate with good latency for any packet rate. This is hardware interrupt coelescing. It is a totally seperate thing. The point of DEVICE_POLLING is to avoid the receiver livelock case, when you are under extreme load. What this probably means is that you haven't put enough load on the hardware to see the livelock case. Given enough load, the 'ticks' trigger never fires: you are getting enough packets that, even if you divide by 128 ('bds'), you are still in trouble. The problem is that at 128 'bds', you end up spending 128 times as long in the interrupt handler, so all you are saving is the trigger latency. This pushes the top end before livelock higher, but it doesn't prevent it. You also delay packet processing on up to 'bds - 1' packets that are received in the 'ticks' window, before the 'bds'th packet comes in, so you increase your mbuf pool size for unprocessed packets. This doesn't really affect performance, per se, but it will reduce the total number of simultaneous connections you are able to support at a given client load on a web server (for example). The DEVICE_POLLING option doesn't just get rid of interrupts; what it does is delays packet input until the rest of the system is ready to handle the packets. It's not actually ideal; really, you want to tell the hardware to stop DMA'ing into packet buffers, so that you don't eat the bus latency while you are not polling for more data. A number as high as 128 (depending on the firmware) can actually be a bad thing. Bottom line is that, until a full LRP is integrated, the best performance you are going to be able to get is DEVICE_POLLING, and it doesn't really matter how much you can amortize the interrupt overhead. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message