PERFORCE change 161793 for review

Marko Zec zec at freebsd.org
Mon May 11 02:35:18 UTC 2009


On Saturday 09 May 2009 21:15:41 Brooks Davis wrote:
> On Fri, May 08, 2009 at 09:44:20PM +0000, Marko Zec wrote:
> > http://perforce.freebsd.org/chv.cgi?CH=161793
> >
> > Change 161793 by zec at zec_tpx32 on 2009/05/08 21:43:51
> >
> > 	A controversial hack: when allocating if_unit numbers for
> > 	cloning ifnets, do NOT resort to bitmap mappings, but
> > 	iterate through all existing ifnets in a particular vnet
> > 	as long as a free unit number is found.
> >
> > 	The problem here is that we are switchng from a O(n) to
> > 	a O(n**2) search method with more work being done in each
> > 	iteration.  So this should be revisited RSN.
>
> IMO the best solution for now is to retain the global namespace and
> thus not worry about virtualizing this any more than we do for em0.

It's not that simple - don't forget that we need to have lo0 in each vnet due 
to expectations from various userland applications.  Moreover, users of 
cloning ifnets would expect to get (as an example) vlan0, vlan1, vlan2 when 
issuing ifconfig vlan create, not vlan539, vlan1, vlan123 etc.  The same goes 
for tunneling interfaces, ng_eiface, ng_iface etc.  I think the general 
principle behind vimage / vnets was not to allow for any information leakages 
between the isolated contexts, and retaining global namespace for cloning 
ifnets would significantly violate that principle.

> This must not make it in to current since if it did, users with tunnel
> brokers would be very unhappy.

Precisely for the sake of tunnel brokers, I think each vnet should have its 
own namespace for cloning devices - and this has nothing to do with "em0" or 
any other physical ifnet which does not use the if_clone infrastructure.  I 
agree that the O(n**2) code for searching for free ifunits should not get 
commited into svn, but Julian and I already discussed how we could virtualize 
the existing O(n) bitmapped algorithm in if_clone.c, and will try to submit 
and test an alternative in p4 in the next few days.

Marko


More information about the p4-projects mailing list