Date: Sun, 2 Sep 2007 14:19:45 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: Max Laier <max@love2party.net>, net@freebsd.org Subject: Re: Allocating AF constants for vendors. Message-ID: <20070902211945.GQ87451@elvis.mu.org> In-Reply-To: <46CC45F0.3000105@FreeBSD.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bruce M. Simpson <bms@FreeBSD.org> [070822 07:33] wrote: > I second Max. If you are going to introduce a bunch of AF_* constants > into the tree you have to be very careful as AF_MAX is used to size > arrays and figure out how many radix trie heads to allocate. Ok, I'm not really sure what to do here. At Juniper we have approx 20 additional entries for AF_ constants. We also have theoretical but not practical "problems" with spareness and utility of this list, meaning we have plenty of arrays in our version of ifnets and route entries that are also "bloated" as well. We happen not to find it a problem. Perhaps if $BIG_ROUTER_COMPANY is not concerned about this then that might be convincing enough to let it go? Perhaps if I tossed in that it would be my intention to share code to dynamically allocate the data if we ever did it ourselves. Otherwise one other policy would be to specify an allocation policy such that new AF_ constants are allocated only for even numbers where odd numbers are left to vendors. This would slow the "bloat" and still provide vendors with something useful. How does that sound? -Alfred > > It could be argued this wastes a bunch of CPU time and memory, though I > speculate 'not much' at the moment; I am just a bit concerned that we > have ifnet->if_afdata which is also sized based on AF_MAX, 37, even > though most of the protocols in it are never attached to ifnets. > > The only domain I've seen which really uses if_afdata is PF_INET6. > PF_INET does not use it at all. In my opinion, there are structures > per-family per-ifnet which really belong hung-off ifnet on a 1:1 basis > and would simplify some of the lazy allocations we have further down in > the stack. > > If AF_MAX increases significantly so will wasted memory. If you are > going to make any significant changes here, please considering moving > this stuff to a more dynamic method of allocation. > > On the other hand, if you don't need to reference these constants in the > kernel at all, and they will all exist beyond AF_MAX, then you can > disregard what I've said and append them to the rest of the list. > > That is pretty much what happens for the libpcap/bpf DLT constants > (which are not an exact analogue of the AF constants - we don't allocate > other, larger kernel structures based on their value). > > regards, > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070902211945.GQ87451>