Date: Tue, 09 Aug 2005 18:25:17 +0200 From: Andre Oppermann <andre@freebsd.org> To: Marko Zec <zec@icir.org> Cc: freebsd-net@freebsd.org Subject: Re: Stack virtualization (was: running out of mbufs?) Message-ID: <42F8D8ED.11A196FC@freebsd.org> References: <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote: > > On Tuesday 09 August 2005 14:41, Andre Oppermann wrote: > ... > > I don't want to have non-global interface lists in the kernel. > > But sooner or later you _will_ end up with some sort of non-global > interface lists after all, just as you stated yourself at the beginning > of this tread. Of course one can still maintain all interfaces linked > in one list and introduce another set of separated lists on per-stack > basis which will be used to logically group interfaces into smaller > sets, but that's really just a question of coding / design style. I thinking more along the lines of OpenBSD's interface groups. There you just add another attribute called group to an interface. Claudio (@openbsd.org, working at next desk to me) explained it quickly to me after it was raised here on the list. The group name is a string but in the ifnet structure only an int is stored. This group name then is used primarily for pf firewall to create rules for interface groups. It handles newly arriving interfaces too. I haven't fully explored all applications and possible tie-ins with jails, virtual stacks etc. but it looks very interesting. For example I want to have multiple routing tables within the same stack. These routing tables can be opaque or fall-through and match on the source and destination address (not at the same time though). This way we get ultimate routing flexibility in using FreeBSD as router. An incoming packet on interface em0 with group priority would first match into routing table X, and if no match fall-through to the default routing table. Or you could create a source matching routing table Y sending matching packets further to table Z for low priority routing. It's hard to describe this textually to its full extent. That's why my upcoming paper will have mostly graphics depicting the packet flow and the processing options. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F8D8ED.11A196FC>