From owner-freebsd-hackers Mon Aug 11 09:04:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12324 for hackers-outgoing; Mon, 11 Aug 1997 09:04:22 -0700 (PDT) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA12318 for ; Mon, 11 Aug 1997 09:04:16 -0700 (PDT) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id JAA09453; Mon, 11 Aug 1997 09:04:13 -0700 (PDT) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Mon, 11 Aug 1997 09:04:13 -0700 (PDT) From: Curt Sampson To: Chris Csanady cc: freebsd-hackers@FreeBSD.ORG Subject: Re: DISCUSS: interface for raw network driver.. In-Reply-To: <199708110552.AAA01853@friley01.res.iastate.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. 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. 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 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_. 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.