Date: Mon, 2 Jun 2003 13:01:58 -0700 From: Sean Chittenden <sean@chittenden.org> To: Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: Network stack cloning / virtualization patches Message-ID: <20030602200158.GH65470@perrin.int.nxad.com> In-Reply-To: <Pine.BSF.4.21.0305302116350.4662-100000@InterJet.elischer.org> References: <20030530133302.A48390@FreeBSD.org> <Pine.BSF.4.21.0305302116350.4662-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Has anyone looked at making the patch work with CURRENT? Does > > this do anything to degrade performance of UP systems with no (0?) > > virtualised images running? > > I have been running tests between two machines with this patch > installed. There is a "per packet" overhead increase of about 1%. > there is no overhead increase in the per-byte overhead.. in ther > words, sending 1 byte packets gets about a 1% decrease in throughput > but sending 8k chunks has almost no overhead increase.. > > Both my machines end up maxing out the 100Mb ethernet between them > before they see any speed difference at high packet sizes. 1% per packet seems a bit high... where is the overhead coming from? Seems as though there should be less overhead and that lookup of the necessary components for each vimage could be found with a hash... I looked through the patch and couldn't see any places that screamed optimization. Is the overhead really just from copying the data of the vimage around? > > Does it make the locking situation much worse? Can it be stripped > > down to minimal, clean, well-architected diffs to accomplish a > > centralised goal, rather than a "Network+goodies, random subsystem > > overhaul"? > > It is unlikely that the patches could be made in smaller orthogonal > patches. Its kind of "all or nothing".. Either everything is global > or it is in a structure (per VM). *nods* Hrm, it would appear so. > > If this is your priority patch, hunting down someone with serious > > network\ stack-fu to review the diff, and whatnot, would probably > > be a good investment of your time in that regard. > > I'll bepresenting Marco's paper at USENIX on the (ummm 12th I > think). His baby is due then so he can't make it.. (whereas mine > arrived today so I'll be looking for an excuse to be away from the > house for 2 days ;-) :) Congrats (again!)! Julian, am I safe in assuming that you have an interest in this work? If not, I may setup a p4 branch to work with and to merge these bits into -CURRENT if no one else is interested. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030602200158.GH65470>