Freebsd IP Forwarding performance (question,
and some info) [7-stable, current, em, smp]
sepherosa at gmail.com
Tue Jul 1 03:50:25 UTC 2008
On 7/1/08, Pyun YongHyeon <pyunyh at gmail.com> wrote:
> On Tue, Jul 01, 2008 at 11:05:03AM +0800, Sepherosa Ziehau wrote:
> > On 7/1/08, Paul <paul at gtcomm.net> wrote:
> > > All the NIC drivers in 7 pretty much use interrupt moderation so it can
> > I am not quite sure whether em(4)'s RX interrupt moderation works as
> > expected or not. But, AFAIK, nfe(4) and re(4) does not have RX
> > interrupt moderation. Their TX interrupt moderation could be mimiced
> > by using their hardware timer and disabling their TX interrupt.
> > The lacking of RX im is difficult to handle, I could imagine following way:
> > - During init, enable RX intr
> > - When RX intr comes, disable RX intr and set up hardware timer intr
> > - When timer intr comes and no RX happens, disable timer intr and enable RX intr
> I guess adaptive polling would give the same effect withtout
> sacrificing CPU cycles.
The possible wasting is one extra timer intr if there is nothing to
processing at all. But would it be counted as wasting, if the system
was that idle? :)
We will see the result, when I could find some free time to implement it :]
> > Properly configured #RX desc and timer intr interval will be required
> > to make sure that the RX desc collection could keep up with the
> > hardware speed. I used pure timer intr (8000Hz) on nfe(4) in dfly w/
> > good result, i.e. TX/RX @linespeed without livelocking the system.
> I thought that too for a while but I prefer to hardware intertrrupt
> moderation feature. Of course I still have no clue how to enable
> that interrupt feature on nvidia controllers. :-(
RX/TX intr is not affected at all by the so called IMTIMER register.
The IMTIMER register is actually only a hardware timer counter
register. I took a look at Linux's forcedeth several days ago, but I
didn't see anything improved in that area.
Live Free or Die
More information about the freebsd-net