From owner-freebsd-hackers Mon Aug 11 19:54:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA20739 for hackers-outgoing; Mon, 11 Aug 1997 19:54:21 -0700 (PDT) Received: from friley01.res.iastate.edu (friley01.res.iastate.edu [129.186.189.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA20728 for ; Mon, 11 Aug 1997 19:54:15 -0700 (PDT) Received: from friley01.res.iastate.edu (loopback [127.0.0.1]) by friley01.res.iastate.edu (8.8.7/8.8.5) with ESMTP id VAA04339; Mon, 11 Aug 1997 21:54:20 -0500 (CDT) Message-Id: <199708120254.VAA04339@friley01.res.iastate.edu> X-Mailer: exmh version 2.0zeta 7/24/97 To: Curt Sampson Cc: freebsd-hackers@freebsd.org Subject: Re: DISCUSS: interface for raw network driver.. In-reply-to: Your message of "Mon, 11 Aug 1997 09:04:13 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Aug 1997 21:54:20 -0500 From: Chris Csanady Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I should preface this post with the comment that I'm not any huge >expert on high performance networking; I just read up on it when >I can. > >On Mon, 11 Aug 1997, Chris Csanady wrote: > >> o An ack function in the pseudo-device to call when the send is complete. >> ... >> o An input function in the pseudo-device to be called upon reception of >> a packet. > >If you're interested in performance, you want to batch these as >much as possible to avoid interrupts. You should be able to chain >sends, at the very least. Possibly even better, if you're really >slamming stuff through the interface, would be for the application >to have a whole series of buffers that it fills and adds to the >chain, and when it runs out (or comes near to running out), a >function it can call to get a list of the buffers that have been >sent and are now free. Of course, there's some work to do here >regarding the best way to feed errors back to the application. This is not a bad idea, and would be fairly simple to implement. >For receive packets, you have to figure out what sort of trade-off >you want to make between latency and speed, and this is really an >application decision. If possible, deal with the reception of >several packets with just one interrupt. What I currently have in my driver allows for multiple receive packets to be serviced at interrupt time. However, if you only interrupt so often, you will have to implement a timeout mechanism as well. >But in the end, your whole strategy is not the right way to go as >far as really good performance, except in the (in these days unusual) >case where the application uses its own private protocol. If you But we do want to use our own protocol. The end goal is to use this as a bottom end for MPI or other parallel applications/etc.. >want to see how to deal with TCP/IP over Gigabit Ethernet, I really >strongly recommend reading ``DART: Fast Application-Level Networking >via Data-Copy Avoidance'' by Robert J. Walsh in The July/August >1997 (v 11 n 4) issue of _IEEE Network_. Do you have a url? Although I definately don't have the time to reimplement a large chunck of the TCP/IP stack, I am definately interested. I was hoping to work on implementing Van's pbuf architecture this summer, but I haven't had the time. Overall, I think that in the end, a real protocol is the way to go.. although there are just none that are efficient enough to take advantage of todays high speed networks. Chris > >cjs > >Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ >Internet Portal Services, Inc. Through infinite myst, software reverberates >Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. >