running out of mbufs?

[Andre Oppermann]

Marko Zec wrote:
> 
> On Monday 08 August 2005 12:32, Andre Oppermann wrote:
> > Dave+Seddon wrote:
> > > BTW, I'd be interested to know people's thoughts on multiple IP
> > > stacks on FreeBSD.  It would be really cool to be able to give a
> > > jail it's own IP stack bound to a VLAN interface.  It could then be
> > > like a VRF on Cisco.
> >
> > There is a patch doing that for FreeBSD 4.x.  However while
> > interesting it is not the way to go.  You don't want to have multiple
> > parallel stacks but just multiple routing tables and interface groups
> > one per jail. This gives you the same functionality as Cisco VRF but
> > is far less intrusive to the kernel.
> 
> Andre,
> 
> the stack virtualization framework for 4.x is based precisely on
> introducing multiple routing tables and interface groups.  In order to
> cleanly implement support for multiple independent interface groups,
> one has to touch both the link and network layers, not forgetting the
> ARP stuff... and in no time you have ended up with a huge and intrusive
> diff against the original network stack code.

While your stack indexing approach is interesting I don't think it is
the way we should take for the generic FreeBSD.  There are better ways
to implement a less limiting superset of the desired functionality.
And the ARP is almost done, I have to review the code and then it goes
into -current.

> So I see no point in pretending we could get such a functionality for
> free, i.e. with only a negligible intrusiveness to the kernel code.  A
> more appropriate question would be whether the potential benefits of
> having multiple stack state instances could outweight the trouble and
> damage associated with the scope of required modifications to the
> kernel code tree.  Only if we could get an affirmative answer to that
> question it would make sense to start thinking / debating on the most
> appropriate methodology to (re)implement the multiple stacks framework.

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.

What I have in mind is a redesign of some parts of the stack as such.
I have got funding to work on this through my fundraise of two weeks
ago.  Work is about to start later this week.  I will provide a more
detailed design document for discussion and review by the FreeBSD
community in a few days.  It will include features such as multiple
hierarchical routing tables (bound to jails or not), interface groups,
virtual interfaces belonging to one or more interface groups, policy
routing (based on source address/interface), multi-path routing, a
reworked routing-socket and some more stuff.

I recommend waiting for the design document for further discussions
and jumping to any conclusions. :)

-- 
Andre