Received: by oss.sgi.com id ; Tue, 9 Jan 2001 04:05:25 -0800 Received: from chiara.elte.hu ([157.181.150.200]:5132 "HELO chiara.elte.hu") by oss.sgi.com with SMTP id ; Tue, 9 Jan 2001 04:05:15 -0800 Received: by chiara.elte.hu (Postfix, from userid 17806) id 05F91186D; Tue, 9 Jan 2001 13:05:09 +0100 (CET) Date: Tue, 9 Jan 2001 13:04:49 +0100 (CET) From: Ingo Molnar Reply-To: To: Christoph Hellwig Cc: "David S. Miller" , , , Subject: Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1 In-Reply-To: <20010109122810.A3115@caldera.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Content-Length: 2010 Lines: 43 On Tue, 9 Jan 2001, Christoph Hellwig wrote: > Sure. But sendfile is not one of the fundamental UNIX operations... Neither were eg. kernel-based semaphores. So what? Unix wasnt perfect and isnt perfect - but it was a (very) good starting point. If you are arguing against the existence or importance of sendfile() you should re-think, sendfile() is a unique (and important) interface because it enables moving information between files (streams) without involving any interim user-space memory buffer. No original Unix API did this AFAIK, so we obviously had to add it. It's an important Linux API category. > If there was no alternative to this I would probably have not said > anything, but with the rw_kiovec file op just before the door I don't > see any reason to add this _very_ specific file operation. I do think that the kiovec code has to be rewritten substantially before it can be used for networking zero-copy, so right now we do the least damange if we do not increase the coverage of kiovec code. > An alloc_kiovec before and an free_kiovec after the actual call and > the memory overhaed of a kiobuf won't hurt so much that it stands > against a clean interface, IMHO. please study the networking portions of the zerocopy patch and you'll see why this is not desirable. An alloc_kiovec()/free_kiovec() is exactly the thing we cannot afford in a sendfile() operation. sendfile() is lightweight, the setup times of kiovecs are not. basically the current kiovec design does not deal with the realities of high-speed, featherweight networking. DO NOT talk in hypotheticals. The code is there, do it, measure it. You might not care about performance, we do. another, more theoretical issue is that i think the kernel should not be littered with multi-page interfaces, we should keep the one "struct page * at a time" interfaces. Eg. check out how the new zerocopy code generates perfect MTU sized frames via the ->writepage() interface. No interim container objects are necessary. Ingo