Date: Tue, 04 Sep 2007 11:11:06 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Max Laier <max@love2party.net>, net@freebsd.org Subject: Re: Allocating AF constants for vendors. Message-ID: <46DD2F3A.20904@FreeBSD.org> In-Reply-To: <20070903201133.GU87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: >> Can you merge them into the list in such a way that AF_MAX does not need >> to slide forward? >> Or do they need to be referenced from within the kernel tree itself? >> > > They are refenced inside the kernel. > Let me rephrase that: are protocol domains attached in the kernel using these constants? Pull an AF_MAX 'referenced from' list from kscope or fxr.watson.org and you'll see what I mean - we use this constant in a LOT of places, particularly in the socket path, it is used to bound loops and allocate static array space. 1 extra slot won't make much difference, 20 will -- and this is why it's an invasive change. >> Prevention of code bloat is better than the cure. Not having the code >> in front of me I couldn't say for sure if we're talking about a dozen >> bytes or several pages potentially being wasted, so it is impossible to >> judge. >> > > Well, for the most part it's going to be something like 32*sizeof(void*) > so 128 or 256 bytes depending on arch. > Adding bloat to ifnet is far from ideal. It isn't a show stopper for most use cases, but there are folk out there who use FreeBSD as a VPN access concentrator, and creating 10,000 ifnets for their purposes is not out of the question for them. There is also the case of smaller embedded systems. It might not seem like a lot now, but it could be a show stopper for some. >> One of my concerns is that we have ifnet.if_afdata, we're not really >> using it, it makes sense to use it for some things. >> > > I'll have ot look into this. > To give examples: Consider for example the case of the 'router_info' structure in IGMP. Its relationship cardinality w.r.t struct ifnet is 1:1 - for each ifnet, there is a router_info - but only if AF_INET is attached to that ifnet. This is where if_afdata is typically used. I would like to take the per-link IPv4 stack structures and hang them off ifnet directly. Reasons: 1. Lazy allocation of router_info leads to potential races in igmp. These are worked around by constantly checking if a struct is allocated or deallocated upon any reference to them. Easy to do in C++. Tedious and error prone in C. The struct also needs to be garbage collected when an ifnet goes away. 2. We can potentially move protocol domain addresses for upper layers into their own struct. We don't lock a global address list every time we perform an address operation. 3. Right now, we can't detach and re-attach protocol stacks to ifnets. A number of folks are affected, particularly for IPv6, where there are perfectly legitimate reasons to bounce the stack in this way, say, link-local addresses get screwed up, or even just need to be enabled. > As you can see we are defering the "bloat". > Does that make sense? > I follow but it still doesn't really make sense. Granted, you are deferring the growth of arrays sized off AF_MAX but only ever by 1 slot. What if Vendor Z wants to add 25 entries at once? We would also be tying ourselves down to the notion of a vendor in any AF_ allocation. Is this an avenue that people are happy to pursue? regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46DD2F3A.20904>