Re: Network stack cloning / virtualization patches

From: Marko Zec (zec_at_tel.fer.hr)
Date: 05/30/03

  • Next message: Matthew D. Fuller: "Re: Collision on NIC" 
    Date: Fri, 30 May 2003 22:07:07 +0200
To: Juli Mallett <jmallett@FreeBSD.org>

    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

    _______________________________________________
    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"

  • Next message: Matthew D. Fuller: "Re: Collision on NIC"

    Relevant Pages

    • Re: Network stack cloning / virtualization patches
      ... > be stripped down to minimal, clean, well-architected diffs to accomplish ... > gets too close to the tree. ... virtualize and which not. ... but I hope to hear some feedback though... ...
      (freebsd-hackers)
    • Re: Female watchmakers
      ... Frank Adam wrote: ... and do accomplish many things beyond traditional home-maker based ... technical and scientic pursuits is no longer the exception to the rule. ... Go hug a tree. ...
      (alt.horology)
    • #inject:into: What a Gem!
      ... bracketed notation of a tree ... I was able to accomplish this with merely the following code: ... This kind of parsing is usually a mess in other languages. ...
      (comp.lang.smalltalk.dolphin)
    • Re: XFS for FreeBSD, new snapshot available
      ... +>>>You'll get more feedback if the code is in the tree, ... +>>>precedent for committing filessystems without write support. ... there was no feedback when kan@ had posted last snapshot. ...
      (freebsd-current)
    • Re: [PATCH 12/11] sched: rt-group: uid-group interface
      ... I will try out these patches and try to give you some ... feedback. ... Should I just make an incremental patch akpm can carry ... Or can we base one tree off the other? ...
      (Linux-Kernel)