From owner-freebsd-hackers Wed Nov 20 12:45:58 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 016E737B401 for ; Wed, 20 Nov 2002 12:45:57 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 608F943E3B for ; Wed, 20 Nov 2002 12:45:56 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9W3BS>; Wed, 20 Nov 2002 15:45:55 -0500 Message-ID: From: Don Bowman To: 'Terry Lambert' , 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: Netgraph couldbe a router also) Date: Wed, 20 Nov 2002 15:45:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 > From: Terry Lambert [mailto:tlambert2@mindspring.com] > 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. > Actually I have pushed it to the livelock case. I'm shocked at how easy this is to do with BSD (I'm used to system like vxworks with much lower over head interrupt processing). I found that for a 2x XEON @ 2GHz that I can achieve this @ ~100Mbps of minimal size UDP fragments. Tuning the driver dramatically improved the situation. Reducing the size of its receive ring to the proper amount also helps since it will then run out of buffers and drop packets. This isn't extreme load, it isn't really particularly heavy load, its only like ~200Kpps. I suspect the defragmenting is the issue, so I tried it again with ARP's. This helped a lot. I'm still not clear on how the receiver polling helps me, it also makes a constant rate consumption of packets. If I set the bds to the max, then I will only be interrupted @ constant rate by the device. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message