Date: Fri, 30 May 2003 22:07:07 +0200 From: Marko Zec <zec@tel.fer.hr> To: Juli Mallett <jmallett@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: Network stack cloning / virtualization patches Message-ID: <3ED7B9EB.9719E0FB@tel.fer.hr> References: <3ED14BF3.139CAC32@tel.fer.hr> <20030530182645.GP62688@perrin.int.nxad.com> <20030530133302.A48390@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Juli Mallett wrote: > * Sean Chittenden <sean@chittenden.org> [ Date: 2003-05-30 ] > [ w.r.t. Re: Network stack cloning / virtualization patches ] > > > at http://www.tel.fer.hr/zec/vimage/ you can find a set of patches > > > against 4.8-RELEASE kernel that provide support for network stack > > > cloning. > > > > Has anyone stepped forward to possibly shepherd this code into the > > tree? I am highly interested in this code and would like to see it > > incorporated into the base system (read: -CURRENT, before 5.2). After > > looking at the TODO, I realize that this patch isn't 100% yet, but can > > it be broken down into a smaller set of commits? > > 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? 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"? Those are probably good questions for someone to know the > answers to (by looking at the code, or someone trying such) before it > gets too close to the tree. I plan to start porting the cloning code to -CURRENT once it becomes -STABLE (that means once the 5.2 gets out, I guess). In the meanwhile I'd like to get more feedback on what people like / dislike regarding the general concept and the code as it is right now, in which direction I should strive to redesign the management API etc. I fully agree with Juli's comment that the patch coalesces many things not fundamentally related to the network stack itself, and that it therefore has to be slightly reengineered first. While at BSDCon in Amsterdam, idowse@ and phk@ suggested to me that the vimage framework should probably be implemented in a more modular fashion, so that admins could choose which system resources to virtualize and which not. My current experiments are going in that direction... Regarding the question on performance penalty, I suggest that you check the EuroBSDCon slides which provide a basic comparison between the standard and the patched kernel. The overhead increase is generally hardly measurable, and depending on traffic type it does not exceed 3-4% in worst case scenarios. Julian Elischer will be giving a talk accompanying a paper on the subject at the upcoming USENIX / FreeNIX ATC, so perhaps this could also be a good place to learn a couple of more details :-) Unfortunately I won't be able to attend the conference personally :-| , but I hope to hear some feedback though... Cheers, Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED7B9EB.9719E0FB>