Network stack cloning / virtualization patches
zec at tel.fer.hr
Fri May 30 13:07:26 PDT 2003
Juli Mallett wrote:
> * Sean Chittenden <sean at 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...
More information about the freebsd-hackers