Stack virtualization (was Re: running out of mbufs?)

[Milan Obuch]

On Tuesday 09 August 2005 11:04, Marko Zec wrote:
> On Monday 08 August 2005 18:47, Andre Oppermann wrote:

...

> Andre,
>
> there's no doubt almost any idea or particularly software can be
> improved.  Could you provide a more elaborate argumentation to your
> claim the network stack cloning concept is so severely limited that it
> has no place to search for in the future of FreeBSD?
...
>

I am coming to this talk having used Marko's patch once and planning to use it 
again for similar task if nothing better will be available (which almost 
surely will not be the case in not too distant future).
The only one problem with it is not being -current or 5/6 release based, so 
the whole thing needs to be implemented anew in new kernel environment.

...

> > Having multiple stacks duplicates a lot of structures for each stack
> > which don't have to be duplicated.  With your approach you need a new
> > jail for every new stack.  In each jail you have to run a new
> > instance of a routing daemon (if you do routing).  And it precludes
> > having one routing daemon managing multiple routing tables.  While
> > removing one limitation you create some new ones in addition to the
> > complexity.
>
> Bemusingly, none of the above claims are true.
>
> A new jail for each network stack instance is NOT required.  Inside the
> kernel what could be considered "per-jail" and per-network stack
> structures are cleanly separated and independent.  In fact, one can run
> multiple jails bound to a single network stack instance, if desired.
>
> Furthermore, a single process can simultaneously attach to multiple
> network stacks, thus potentially allowing a single routing daemon to
> manage multiple separated routing tables and interface groups.  The
> entity that gets permanently bound to a network stack instance is a
> socket and not a process. This translates to the capability of a single
> process to open multiple sockets in multiple independent stacks.  IMO,
> one particular strength of such an approach is that it requires
> absolutely no extensions or modifications to the existing routing
> socket API.
>
> And finally, I'm wondering what structures exactly are you referring to
> when you say that this approach "duplicates a lot of structures for
> each stack which don't have to be duplicated"?  I absolutely agree that
> the virtualization of the network stack should be done as simple and
> non-intrusive as possible, but my point is that it just cannot be done
> cleanly / properly without taking some sacrifices in terms of the scope
> of minimum required modifications.
>

As I am no network code guru, I can only tell from reading presentation papers 
and some material on this issue virtualisation as done by Marko meets most of 
above mentioned criteria already. I would like to stress its easiness of use 
- no application modification is necessary, but one could surely make new 
application (or modify old one, for that matter) aware of stack 
virtualization - routing daemon could benefit here.

Only argument against Marko's work could be it's monolithic, which does 
interfere with current movement towards modular network infrastructure, so 
new protocol could be kldload'ed.

To me this would be great start - it does work well, it is usable in many 
various scenarios already and it *is* well structured, even easy to 
understand (at least at conceptual level, code itself is somewhat more 
complicated).

Milan