Received: with ECARTIS (v1.0.0; list netdev); Mon, 21 Mar 2005 23:41:32 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id j2M7fNPI025768 for ; Mon, 21 Mar 2005 23:41:24 -0800 Received: (qmail 65498 invoked by uid 3709); 22 Mar 2005 07:41:22 -0000 Date: 22 Mar 2005 08:41:22 +0100 Date: Tue, 22 Mar 2005 08:41:22 +0100 From: Andi Kleen To: John Heffner Cc: Stephen Hemminger , baruch@ev-en.org, netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers Message-ID: <20050322074122.GA64595@muc.de> References: <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 02:48:43 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1561 Lines: 40 On Mon, Mar 21, 2005 at 04:25:56PM -0500, John Heffner wrote: > On Sat, 19 Mar 2005, Andi Kleen wrote: > > > Stephen Hemminger writes: > > > > > Since developers want to experiment with different congestion > > > control mechanisms, and the kernel is getting bloated with overlapping > > > data structure and code for multiple algorithms; here is a patch to > > > split out the Reno, Vegas, Westwood, BIC congestion control stuff > > > into an infrastructure similar to the I/O schedulers. > > > > [...] > > > > Did you do any benchmarks to check that wont slow it down? > > > > I would recommend to try it on a IA64 machine if possible. In the > > past we found that adding indirect function calls on IA64 to networking > > caused measurable slowdowns in macrobenchmarks. > > In that case it was LSM callbacks, but your code looks like it will > > add even more. > > Is there a canonical benchmark? For the LSM case we saw the problem with running netperf over loopback. It added one or two hooks per packet, but it already made a noticeable difference on IA64 boxes. On other systems it is unnoticeable. > Would you really expect a single extra indirect call per ack to have a > significant performance impact? This is surprising to me. Where does the > cost come from? Replacing instruction cache lines? I was never quite clear. Some instruction stalls in the CPUs. One not very good theory was that McKinley really likes to have its jump registers loaded early for indirect calls, and gcc doesn't even attempt this. -Andi