Date: Wed, 20 Nov 2002 10:16:57 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Don Bowman <don@sandvine.com> 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) Message-ID: <3DDBD199.4FB8FDA0@mindspring.com> References: <FE045D4D9F7AED4CBFF1B3B813C8533701022FB8@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDBD199.4FB8FDA0>