Date: Wed, 8 Nov 2006 21:24:03 -0800 From: "Jack Vogel" <jfvogel@gmail.com> To: "Sam Wun" <smw2010@gmail.com> Cc: Scott Long <scottl@samsco.org>, RelEng <re@freebsd.org>, John Baldwin <jhb@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch Message-ID: <2a41acea0611082124x4143289emb0c3e0dee3e50ecc@mail.gmail.com> In-Reply-To: <ff64092b0611082035u5f7d248dg3465ef8c54160451@mail.gmail.com> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <ff64092b0611082035u5f7d248dg3465ef8c54160451@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/8/06, Sam Wun <smw2010@gmail.com> 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 RELEASE. Does that answer your question Sam? Regards, Jack > > On 11/9/06, Jack Vogel < jfvogel@gmail.com> 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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to " > freebsd-net-unsubscribe@freebsd.org" > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0611082124x4143289emb0c3e0dee3e50ecc>