Allocating AF constants for vendors.
alfred at freebsd.org
Sun Sep 2 14:22:32 PDT 2007
* Bruce M. Simpson <bms at 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
How does that sound?
> 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).
> freebsd-net at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
- Alfred Perlstein
More information about the freebsd-net