From owner-freebsd-hackers Fri Nov 14 05:09:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26553 for hackers-outgoing; Fri, 14 Nov 1997 05:09:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26546 for ; Fri, 14 Nov 1997 05:09:27 -0800 (PST) (envelope-from mouth@ibm.net) Received: from slip129-37-53-71.ca.us.ibm.net (slip129-37-53-71.ca.us.ibm.net [129.37.53.71]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id NAA55264; Fri, 14 Nov 1997 13:09:18 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans Cc: bde@zeta.org.au, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Date: Fri, 14 Nov 1997 14:10:33 GMT Message-ID: <346c51c4.1329130@smtp-gw01.ny.us.ibm.net> References: <199711140928.UAA25820@godzilla.zeta.org.au> In-Reply-To: <199711140928.UAA25820@godzilla.zeta.org.au> X-Mailer: Forte Agent 1.01/16.397 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id FAA26547 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 14 Nov 1997 20:28:05 +1100, Bruce Evans wrote: >>In the case of a multiport serial adapter, each port could have a flag >>in sio.c which tells whether it's working in polled mode or interrupt >>mode. Whenever you poll the ports which are streaming data in, you >>would only have to check the ones which have their polling flag on, >>because any of the other ports not being polled would still get your >>attention by means of an interrupt. > >I don't see how to make this work with edge-triggered interrupts. Edge triggered interrupts are not a factor. >E.g., suppose no ports are active and we get an interrupt. Then all >ports must be in interrupt mode and we have to check them all and turn >off the interrupt enables for those that are generating an interrupt. >Then we return from the interrupt and switch to polled mode. This costs >more than the current checking. We still have to check all ports No. >average of 1.5 times around the loop for an average active port found >half way round the loop). There are extra costs for context switching >and toggling the interrupt enables. I also want to pursue some other points in your reply, but I want to clear up this point before proceeding. A port would not be switched to polled mode until its inbound data throughput crosses some defined threshold for some defined period of time -- think of it like a starship making the jump from impulse power to warp drive -- you don't make the switch until you near light speed. :-) As long as data streams in at high speed, you leave the port in polled mode, grabbing its inbound data, not with a fast interrupt, but with a normal scheduled interrupt with other interrupts *enabled*. Remember, it won't matter whether you *always* service the inbound data fast enough, or whether your normal scheduled interrupt is interrupted to run some other task, because the 650 auto RTS will do inbound flow control all by itself. If you see that the inbound FIFO is always full when you start to empty it, you know you are not servicing the data stream fast enough. You can then adjust the scheduling priority and/or time as needed to keep up with the inbound data. That is how you will avoid loss of throughput and efficiency. If the data stream throughput falls below the "warp" threshold, you drop the port back to impulse power -- er, interrupt mode. Each port would be switched individually, according to its data stream throughput (you would have to track that for each port), no matter whether you have an interrupt sharing multiport card, plain old serial cards, or some mix of the two (but only for ports with 650 UARTs). All this would require looking at the kernel scheduling code. That's why I earlier suggested it might take someone foolhardy to attempt it. But for now at least, I only want to know whether the concept is good, without concern for how much work it might require. John