From owner-freebsd-net Sun Oct 28 12:47:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f49.pav2.hotmail.com [64.4.37.49]) by hub.freebsd.org (Postfix) with ESMTP id 80F7D37B401 for ; Sun, 28 Oct 2001 12:47:37 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Oct 2001 12:47:37 -0800 Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP; Sun, 28 Oct 2001 20:47:37 GMT X-Originating-IP: [204.178.20.14] From: "murthy kn" To: rizzo@aciri.org Cc: net@FreeBSD.ORG Subject: Re: Polling vs Interrupts (was Re: NEW CODE: polling support...) Date: Mon, 29 Oct 2001 02:17:37 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Oct 2001 20:47:37.0385 (UTC) FILETIME=[C7053990:01C15FF1] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, First, let me thank for the nice detailed description of polling vs interrupts. I have a couple of questions. > >As the load level increases, your interrupt rate also grows, and >so does the work that you perform in each call to XX_intr(). > >The increase in interrupt rate is dangerous because it can make >you waste a large fraction of your CPU cycles just in overhead and >context switches, leading to a steep drop of the forwarding rate >as the offered load increases. > >The growth in interrupt rate is typically sublinear in the incoming >packet rate, because as the latter increases, it becomes more and >more likely that you get to process a second packet before you can >complete the interrupt service routine. > >This might seem a good thing; but unfortunately, there migth be a >third packet, and a fourth, and a fifth... and so you might remain >within your interrupt service routine for a very large amount of >time (potentially unbounded). This is what makes the system >unresponsive under load, and prevents a fair sharing of resources >among devices. ----------> 1. What will happen if a packet some packets arrive DURING the current call to XXX_intr() - are they processed by the current invocation of XXX_intr() itself without generating a new interrupt or will there be a seperate interrupt for each of those packets ? ( basically, I see a "rcvloop" in the driver code (fxp)) 2. If the answer to the (1) is true, I am not getting the difference between interrupt mitigation/ coalescing described below and the above explanation. Basically, what is being done above is also reducing the number of interrupts (and hence context swithcing overheads) by processing multiple packets in the same call to XXX_intr() ? So, why this kind of becomes a bottleneck whereas interrupt mitigation increases the performance. >write into the status register) and process all events that might have >triggered it -- if you stop early, there might not be another >interrupt that wakes you up to continue the leftover work, so you >have to set a timeout by independent means, or resort to polling. > > >As an example, for a simple I/O read from a register on a PCI card, >I have often measured times as high as 10,000 clock cycles (for >our 750MHz host, this is over 10us) during which the CPU cannot do >anything. Unfortunately, this time is totally unpredictable, and >the CPU has no way to abort the transaction once started. --------> Any pointers on tools/techniques to perform such measurements for instrumenting the kernel will be very helpful. Thanks, Murthy _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message