This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun Dec 10 05:29:40 2023 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HJlii17625 for ; Tue, 17 Sep 2002 21:47:54 +0200 Received: (qmail 3098 invoked from network); 17 Sep 2002 19:40:06 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 19:40:06 -0000 Received: (qmail 5278 invoked by uid 1000); 17 Sep 2002 19:40:04 -0000 MBOX-Line: From linux-kernel-owner@vger.kernel.org Sun Sep 03 07:01:11 2000 Received: (maildatabase); juh Received: (qmail 1123 invoked by alias); 3 Sep 2000 07:01:11 -0000 Received: (qmail 1120 invoked from network); 3 Sep 2000 07:01:10 -0000 Received: from server.ds9a.tudelft.nl (HELO home.ds9a.nl) (10.0.0.1) by spaans.ds9a.nl with SMTP; 3 Sep 2000 07:01:10 -0000 Received: (qmail 14439 invoked by uid 0); 2 Sep 2000 22:00:50 -0000 Received: from vger.kernel.org (199.183.24.194) by home.ds9a.nl with SMTP; 2 Sep 2000 22:00:50 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 2 Sep 2000 18:11:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 2 Sep 2000 18:11:42 -0400 Received: from ix.netcorps.com ([207.1.125.106]:14817 "EHLO ix.netcorps.com") by vger.kernel.org with ESMTP id ; Sat, 2 Sep 2000 18:11:32 -0400 Received: from timpanogas.com ([207.109.151.230]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id OAA17960 for ; Sat, 2 Sep 2000 14:59:44 -0700 (PDT) Message-Id: <39B177CB.DB23F135@timpanogas.com> Date: Sat, 02 Sep 2000 15:57:31 -0600 From: "Jeff V. Merkey" Organization: TRG, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: linux-kernel@vger.kernel.org Subject: [Fwd: zero-copy TCP] Content-Type: multipart/mixed; boundary="------------ADFB01688FF2FCDC69A55B1B" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------ADFB01688FF2FCDC69A55B1B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------ADFB01688FF2FCDC69A55B1B Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <39B1767D.80E159E4@timpanogas.com> Date: Sat, 02 Sep 2000 15:51:57 -0600 From: "Jeff V. Merkey" Organization: TRG, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jes Sorensen Subject: Re: zero-copy TCP References: <39B1705C.F5510B05@timpanogas.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jes, I wrote the SMP ODI networking layer in NetWare that used today by over 90,000,000 NetWare users. I also wrote the SMP LLC8022 Stack, the SMP IPX/SPX Stack, and the SMP OSPF TCPIP stack in NetWare. I think I know what the hell I'm doing here. Most Network protocols assume a primary/secondary relationship. The faster you can get requests in and out of a server, the faster the response time on the client for remote file system operation. What I wrote is THREE TIMES FASTER THAN WHAT'S IN LINUX. Care to do a challenge. Let's take my NetWare code and see which is faster and lower latency on a Network. Mine or Linux's. I bet you $100.00 it will beat the Linux code in every test. Jeff Jes Sorensen wrote: > > >>>>> "Jeff" == Jeff V Merkey writes: > > Jeff, could you start by learning to quote email and not send a full > copy of the entire email you reply to (read rfc1855). > > Jeff> The entire Linux Network subsystem needs an overhaul. The code > Jeff> copies data all over the place. I am at present pulling it apart > Jeff> and porting it to MANOS, and what a mess indeed. In NetWare, the > Jeff> only time data ever gets copied from incoming packets is: > > Try and understand the code before you make such bold statements. > > Jeff> 1. A copy to userspace at a stream head. 2. An incoming write > Jeff> that gets copied into the file cache. > > Jeff> Reads from cache are never copied. In fact, the network server > Jeff> locks a file cache page and sends it unaltered to the network > Jeff> drivers and DMA's directly from it. Since NetWare has WTD's > Jeff> these I/O requests get processed at the highest possible > Jeff> priority. In networking, the enemy is LATENCY for fast > Jeff> performance. That's why NetWare can handle 5000 users and Linux > Jeff> barfs on 100 in similiar tests. Copying increases latency, and > Jeff> the long code paths in the Linux Network layer. > > You can't DMA directly from a file cache page unless you have a > network card that does scatter/gather DMA and surprise surprise, > 80-90% of the cards on the market don't support this. Besides that you > need to do copy-on-write if you want to be able to do zero copy on > write() from user space, marking data copy on write is *expensive* on > x86 SMP boxes since you have to modify the tlb on all > processors. On top of that you have to look at the packet size, for > small packets a copy is often a lot cheaper than modifying the page > tables, even on UP systems so you need a copy/break scheme here. > > As wrt your statement on latency then it's nice to see that you don't > know what you are talking about. Latency is one issue in fast > networking it's far from the only one. Latency is important for > message passing type applications however for bulk data transfers it's > less relevant since you really want deep pipelining here and properly > written applications. If you TCP window is too small even zero latency > will only buy you soo much on a really fast network. > > Jes --------------ADFB01688FF2FCDC69A55B1B-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/