From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264364AbTKZXBu (ORCPT ); Wed, 26 Nov 2003 18:01:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264365AbTKZXBt (ORCPT ); Wed, 26 Nov 2003 18:01:49 -0500 Received: from ns.suse.de ([195.135.220.2]:18135 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264364AbTKZXBs (ORCPT ); Wed, 26 Nov 2003 18:01:48 -0500 Date: Thu, 27 Nov 2003 00:01:45 +0100 From: Andi Kleen To: Trond Myklebust Cc: davem@redhat.com, linux-kernel@vger.kernel.org Subject: Re: Fire Engine?? Message-Id: <20031127000145.61187530.ak@suse.de> In-Reply-To: References: <20031125183035.1c17185a.davem@redhat.com.suse.lists.linux.kernel> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 26 Nov 2003 10:00:09 -0500 Trond Myklebust wrote: > >>>>> " " == Andi Kleen writes: > > > - If they tested TCP-over-NFS then I'm pretty sure Linux lost > ^^^^^^^^^^^^ That would be inefficient 8-) grin. > > badly because the current paths for that are just awfully > > inefficient. > > ...mind elaborating? Current sunrpc does two recvmsgs for each record to first get the record length and then the payload. This means you take all the locks and other overhead twice per packet. Having a special function that peeks directly at the TCP receive queue would be much faster (and falls back to normal recvmsg when there is no data waiting) But that's the really obvious case. I think if you got out an profiler and optimized carefully you could likely make this path much more efficient. Same for sunrpc TX probably, although that seems to be in a better shape already. -Andi