Received: with ECARTIS (v1.0.0; list netdev); Fri, 17 Sep 2004 17:11:15 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i8I0B64a027829 for ; Fri, 17 Sep 2004 17:11:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1C8SoQ-0004TH-00; Sat, 18 Sep 2004 10:10:46 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1C8SoO-0006qX-00; Sat, 18 Sep 2004 10:10:44 +1000 Date: Sat, 18 Sep 2004 10:10:44 +1000 To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@davemloft.net, netdev@oss.sgi.com Subject: Re: [XFRM] Make XFRM core subsystem af-independent Message-ID: <20040918001044.GA24235@gondor.apana.org.au> References: <20040917.231127.114842301.yoshfuji@linux-ipv6.org> <20040917153536.6acec52e.davem@davemloft.net> <20040918.085003.77842779.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040918.085003.77842779.yoshfuji@linux-ipv6.org> User-Agent: Mutt/1.5.6+20040722i From: Herbert Xu X-archive-position: 9043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1250 Lines: 36 On Sat, Sep 18, 2004 at 08:50:03AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > 3. inlined __ip_route_output_flow() + ip_route_output_flow(), ip_route_output_key > - maintenancability will be improved > - breaks binary-only modules. > - code size. > 4. migrate completely (my one) > - maintenancability will be improved > - breaks binary-only modules. > - best stack usage, minimum function call, code size. > - changes more places. You missed the more obvious version of 3: 5. inline ip_route_output_key() only That is exactly the same as 4 except that it doesn't cause ripple effects all over the place. However, I really don't think 16 bytes of stack usage is anything to write home about :) Actually, there is a solution to that as well: 6. Add an inline version of __ip_route_output_flow() in route.c and get ip_route_output_flow/ip_route_output_key to use that. It'll generate code slightly bigger than 2 but is vastly smaller than 4. Otherwise it has all the advantages of 2 and 4. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt