Proposed 6.2 em RELEASE patch

Jack Vogel jfvogel at
Thu Nov 9 05:24:06 UTC 2006

On 11/8/06, Sam Wun <smw2010 at> wrote:
> Without introduced this new patch, can I still use sysctl to maximise its
> performance like FAST_INTR?
> S

Not sure if I'm understanding you, but let me try.

You cannot attain the same receive performance without
the patch. When I use SmartBits and blast UDP packets
at TWO fiber PCI-E NICS and set it to 70% utilization of
the line it will just BURY the system, meaning that the
shell on the console will appear wedged. Once you stop the
test it recovers, but during it its totally consumed handling
interrupts. Perhaps with careful tweaking of everything you
can make things better, but if so that goes beyond my
tuning knowledge. Just one NIC will be OK, and if I drop
the utilization down to 45% its ok, but 50 and up and we
go into the tank, as it were :)

If you compile with EM_FAST_INTR then the system
will continue to operate quite well with the same load.

Now, this is one kind of load, and there is still other types
that work just fine without FAST_INTR, and without the
patch you can still use sysctl to adjust tuning parameters
as your needs vary. BUT, I do not believe you can do as
well as you can with FAST_INTR on, this is why I wanted
to get this code back into the driver conditionally before

Does that answer your question Sam?



> On 11/9/06, Jack Vogel < jfvogel at> wrote:
> >
> > This patch is an evolution of the last one I sent out. It has
> > a couple of minor corrections, like a bad forward decl in
> > the header.
> >
> > The last patch has had quite a bit of testing and all reports
> > have been positive.  The only complaint was from Gleb who
> > says he needs to keep his beloved infinite for loop in the
> > interrupt handler, well I have a better one for you Gleb, keep
> > reading.
> >
> > I have also been doing some extreme stress testing using
> > SmartBits, and discovered the driver as it stands is really
> > not able to take extreme receive side pounding, Scott
> > pointed out that this is why the FAST_INTR work was done :)
> >
> > There were some people that had stability issues with that
> > work, but there were also many that did not. I actually
> > merged the FAST code onto my last patch, and ran the
> > SB stress and found it really was able to gracefully handle
> > that load, way to go Scott :)
> >
> > I've pondered this situation, and this patch I'm including here
> > today is the result. Here's what it does:
> >
> > If you drop it in place, compile it, and go... you will get the
> > code that has been tested for a week, it uses the older
> > style interrupts, it has the watchdog and other SMP fixes
> > so its been proven.
> >
> > BUT, I've added the FAST_INTR changes back into the code, so
> > if you go into your Makefile and add -DEM_FAST_INTR you will
> > then get the taskqueue stuff.
> >
> > So, Gleb, rather than replace the infinite for loop that no one
> > thinks is a good idea, you can just define FAST_INTR again,
> > and you should be good to go.
> >
> > I see this as the best thing for the 6.2 RELEASE, it lets us
> > keep moving forward, people that want max performance
> > can define EM_FAST_INTR and help us wring out any
> > problems, it also will mean that I will have our Intel test
> > group start using this code. But for those that just want
> > a stable driver the standard compile will still give them that.
> >
> > The patch I'm including is against BETA3. Let me know of
> > your concerns or issues.
> >
> > Cheers,
> >
> > Jack
> >
> >
> > _______________________________________________
> > freebsd-net at mailing list
> >
> > To unsubscribe, send any mail to "
> freebsd-net-unsubscribe at"
> >
> >
> >

More information about the freebsd-stable mailing list