Date: Wed, 22 Aug 2007 15:19:28 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: net@freebsd.org Subject: Re: Allocating AF constants for vendors. Message-ID: <46CC45F0.3000105@FreeBSD.org> In-Reply-To: <20070821232956.GT87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46CC45F0.3000105>