Date: Tue, 9 Oct 2001 01:14:08 -0500 From: Alfred Perlstein <bright@mu.org> To: Mike Smith <msmith@freebsd.org> Cc: "Kenneth D. Merry" <ken@kdm.org>, Terry Lambert <tlambert2@mindspring.com>, current@FreeBSD.ORG Subject: Re: Why do soft interrupt coelescing? Message-ID: <20011009011408.S59854@elvis.mu.org> In-Reply-To: <200110090536.f995aKU08231@mass.dis.org>; from msmith@freebsd.org on Mon, Oct 08, 2001 at 10:36:20PM -0700 References: <20011009001857.R59854@elvis.mu.org> <200110090536.f995aKU08231@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Mike Smith <msmith@freebsd.org> [011009 00:25] wrote:
> > * Kenneth D. Merry <ken@kdm.org> [011009 00:11] wrote:
> > >
> > > As you say above, this is actually a good thing. I don't see how this ties
> > > into the patch to introduce some sort of interrupt coalescing into the
> > > ti(4) driver. IMO, you should be able to tweak the coalescing parameters
> > > on the board to do what you want.
> >
> > No matter how hard you tweak the board, an interrupt may still
> > trigger while you process a hardware interrupt, this causes an
> > additional poll which can cause additional coalescing.
>
> I don't think I understand what sort of crack you are smoking.
>
> If an interrupt-worthy condition is asserted on the board, you aren't
> going to leave your typical interrupt handler anyway; this sort of
> coalescing already happens without any "help".
After talking to you on IRC it's become obvious that this doesn't
exactly happen without help. It's more of a side effect of the
way _some_ of the drivers are written.
What I understand from talking to you:
Most smarter drivers or high performance ones will check if the
tx/rx rings have been modified by the hardware and will consume
those packets as well.
However, most drivers have code like this:
if (ifp->if_flags & IFF_RUNNING) {
/* Check RX return ring producer/consumer */
ti_rxeof(sc);
/* Check TX ring producer/consumer */
ti_txeof(sc);
}
Now if more packets come in while in ti_txeof() it seems that
you'll need to take an additional interrupt to get at them.
So Terry's code isn't wrong, but it's not as amazing as one
would initially think, it just avoids a race that can happen
while transmitting packets packets and more arrive or while
recieving packets and the transmit queue drains.
Now, when one is be doing a lot more work in the interrupt context
(or perhaps just running on a slower host processor), Terry's
patches make a lot more sense as there's a much larger window
available for this race.
The fact that receiving is done before transmitting (at least in
the 'ti' driver) makes it an even smaller race as you're less likely
to be performing a lengthy operation inside the tx routine than if
you were doing some magic in the rx routine with incomming packets.
Or at least that's how it seems to me.
Either way, no need to get your latex in a bunch Mike. :-)
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011009011408.S59854>