Date: Wed, 23 Oct 2002 17:43:45 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Marko Zec <zec@tel.fer.hr> Cc: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>, freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: BSD network stack virtualization Message-ID: <Pine.BSF.4.21.0210231737330.36940-100000@InterJet.elischer.org> In-Reply-To: <3DB73F31.5F02609C@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Oct 2002, Marko Zec wrote: > Julian Elischer wrote: > > > > 11/ why was ng_bridge unsuitable for your use? > > Both the native and netgraph bridging code, I believe, were designed with > the presumption that only one "upper" hook is really needed to establish the > communication to kernel's single network stack. However, this concept > doesn't hold on a kernel with multiple network stacks. I just picked the > native bridging code first and extended it to support hooking to multiple > "upper" hooks. The similar extensions have yet to be applied to ng_bridge, I > just didn't have time to implement the same functionality in two different > frameworks. ng_bridge doesn't really distinguish between hooks to upper and lower detinations. it only knows wha tMAC addresses are seen to come from each hook and ensures that packets destined to those addresses are sent to those hooks.. you can have as many 'upper' hooks as you wish (and there are some uses for that). > > > 12/ can you elaborate on the following: > > # fix netgraph interface node naming > > # fix the bugs in base networking code (statistics in > > "native" bridging, additional logic for ng_bridge...) > > When the interface is moved to a different virtual image, it's unit number > gets reassigned, so the interface that was named say "vlan3" in the master > virtual image, will become "vlan0" when assigned to the child. The same > thing happens when the child virtual image returns the interface back to its > parent. The naming of netgraph nodes associated with interfaces (ng_iface, > ng_ether) should be updated accordingly, which is currently not done. > I also considered virtualizing a netgraph stack, this would be also very > cool if each virtual image could manage its own netgraph tree. However, when > weighting implementation priorities, I concluded that this was something > that could wait for other more basic things to be reworked properly first. > Therefore in the current implementation it is possible to manage the > netgraph subsystem only from the "master" virtual image. > > Hope this was enough elaboration for actually testing the code :) it's difficult because my test machines run -current (my 4.x machines are dedicated to production purposes though I may be able try with one.. > > Have fun, Thankyou.. p.s. I should drop down to Croatia next time I'm in Budapest. I'm told it's beautiful. p.p.s cute bear cubs on your site! > > Marko > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210231737330.36940-100000>