From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 21:05:40 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 551ED16A41B; Tue, 4 Sep 2007 21:05:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2900213C474; Tue, 4 Sep 2007 21:05:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2007 13:02:57 -0700 X-IronPort-AV: i="4.20,208,1186383600"; d="scan'208"; a="520363108:sNHT6816829284" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l84K2ui2031800; Tue, 4 Sep 2007 13:02:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l84K2u61022446; Tue, 4 Sep 2007 20:02:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:02:55 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:02:55 -0700 Message-ID: <46DDB9E9.4010408@cisco.com> Date: Tue, 04 Sep 2007 16:02:49 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> <46DD2F3A.20904@FreeBSD.org> <20070904124224.GF87451@elvis.mu.org> In-Reply-To: <20070904124224.GF87451@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 20:02:55.0735 (UTC) FILETIME=[9565A870:01C7EF2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1557; t=1188936176; x=1189800176; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Allocating=20AF=20constants=20for=20vendors. |Sender:=20; bh=jvC+CjhDDtAKaoLeWvmv6qxGRv0RttSpfapR0AkrpzQ=; b=UBzXCwTKuft0nEfr+/ikhzts8tAITfh+2OpeCDMfJYH0ENISSox3M7LLWXRdBcIkCtME5MPa 6z+SmtXNqGC/nGV9YncQTWTt5AIie7A7QL3qJiRTjKaKB0g9ku18xnZE; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: Max Laier , "Bruce M. Simpson" , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 21:05:40 -0000 Alfred Perlstein wrote: > * Bruce M. Simpson [070904 03:08] wrote: > >>>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? > > > Then as long as they allocate odd numbered entries they should > be fine. FreeBSD's AF_MAX does not need to change to accomidate > a vendor, it only has to restrict itself to even numbered slots. > > >>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? > > > Yes, until the "horrific" problem of the statically sized arrays > is "fixed". Then the allocation policy can change. > > So basically in this scheme we only have to "stumble" across an additional slot when we add a new one to FreeBSD.. i.e. some random vendor may assign 50 slots (in odd numbers) but FreeBSD would not see the growth until really 2 new AF_XXX's are added. Then you would have to bump it from by 3, to cover the two new ones (reserving the vendor specific slots and thus causing allocations of unused things). This seems like a reasonable compromise to me... I can't imagine where we would need to add a lont of new AF_XXX's.. of course maybe I just lack imagination :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)