Re: VIMAGE (was: Multiple default routes / Force external routing)
Thanks, Marco, > > > > is VIMAGE fully integrated into FreeBSD 8 CURRENT? (I believe this > > > > answer is no) > > > > also is VIMAGE expected to make it into FreeBSD 8? > > > > > > not fully but a lot of it is under way > > > > Thanks for the pointer, I currently don't get it [1] to build on > RELENG_7 > > which I naively hoped, so the "lot" probably not suffient for me yet. > So, > > w/o patience for August, I probably need to find another way. > > Hmm... > tpx32% uname -a > FreeBSD tpx32.icir.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 5 > 22:36:40 > CET 2009 > ma...@tpx32.icir.org:/u/marko/p4/zec/vimage_7/src/sys/i386/compile/VIMAGE > i386 > tpx32% pwd > /u/marko/tmp > tpx32% tar -xzf vimage_7_20090401.tgz > tpx32% cd src/sys/i386/conf/ > tpx32% config VIMAGE > tpx32% cd ../compile/VIMAGE/ > tpx32% make depend; make > tpx32% sudo make install > tpx32% cd ~/tmp/src/usr.sbin/vimage/ > tpx32% make clean; make > tpx32% sudo make install > > Let me know if that doesn't work... In fact, it *does* work, thank you. I mistook the tar to be a patch to copy over an existing tree which obviously did not work out as I expected. So, how's that: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-PRERELEASE #0: Sat Apr 25 08:22:26 UTC 2009 r...@netserv.ka.cornelius:/usr/src.VIMAGE_20090401/sys/i386/compile/VNETSERV Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 1610596352 (1535 MB) avail memory = 1568624640 (1495 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 (...) So, I suppose it's further reading time and then I'll go and set up a couple of vimages and see what it does... :) Thanks again, Peter. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
--- On Fri, 4/24/09, Ed Maste wrote: > From: Ed Maste > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Friday, April 24, 2009, 1:42 PM > On Fri, Apr 24, 2009 at 08:03:52AM -0700, Barney Cordoba > wrote: > > > Actually, the "advantage of using > interrupts" is to have a per > > NIC control without having all of the extra code to > implement > > polling. Using variable interrupt moderation is much > more desirable > > and efficient, so polling is only useful for legacy > NICs with no > > controls on interrupt delays. > > I'm aware of the advantages and tradeoffs of the > various approaches, > and the shortcomings of our current polling infrastructure, > probably > the greatest of which is the lack of any parallelism. That > said, in > testing some time ago polling with the modifications I > alluded to in > my email, using em(4), gave the highest throughput of all > approaches. > (At the expence of latency, as expected.) > > In addition, having a standardized polling interface allows > for use of > the interface when the system is not fully running -- > network > crashdumps, for instance. > > We can certainly use improvements in the polling > infrastructure though, > at least allowing it to properly take advantage of SMP. > The KPI change > proposed here is to allow some of those improvements, > should they > happen, to be MFC'd to 8. > > -Ed "highest performance" measured in what way, and in comparision to what set of moderation controls? Did your "tests" consider that polling implements a direct method of managing the NIC while interrupts use the highly questionable method of launching tasks? If you didn't test against interrupt methods that manage the NIC in the same way then you've compared apples to oranges. The proper way to do it would be to have your interrupt routine call the polling function (ie using the moderated interrupt to initiate the poll). Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in soabort
On Fri, 24 Apr 2009, pluknet wrote: 2009/4/23 Robert Watson : On Thu, 23 Apr 2009, pluknet wrote: Please, give me comment on this. The panic is on 6.2-REL. Is it known to be fixed in the latter releases? It may well be -- there have been quite significant architectural improvements to socket life cycle (etc) between 6.2 and 7.x releases, which may well close the race causing this panic. However, we'll probably need to learn a bit more in order to decide for sure. Could you convert the trapping instruction pointer to file+offset in the source code? Looks I've lost the corresponding kernel.debug. Anyway I have such bt the first time. If you run into this again, let me know. Also, are you using accept filters on the box? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: panic in soabort
2009/4/25 Robert Watson : > > On Fri, 24 Apr 2009, pluknet wrote: > >> 2009/4/23 Robert Watson : >>> >>> On Thu, 23 Apr 2009, pluknet wrote: >>> Please, give me comment on this. The panic is on 6.2-REL. Is it known to be fixed in the latter releases? >>> >>> It may well be -- there have been quite significant architectural >>> improvements to socket life cycle (etc) between 6.2 and 7.x releases, which >>> may well close the race causing this panic. However, we'll probably need to >>> learn a bit more in order to decide for sure. Could you convert the >>> trapping instruction pointer to file+offset in the source code? >> >> Looks I've lost the corresponding kernel.debug. Anyway I have such bt the >> first time. > > If you run into this again, let me know. Also, are you using accept filters > on the box? > [started to think about adding dumpdev="AUTO" to rc.conf]. Not on this one now, but we are going to massively switch to accf_http in some near future, if that would give us an appropriate gain. > Robert N M Watson > Computer Laboratory > University of Cambridge > -- wbr, pluknet ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
