Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA7686 ; Mon, 25 Jan 93 12:20:03 EST Xref: sserve comp.unix.bsd:10363 alt.sources:5037 Newsgroups: comp.unix.bsd,alt.sources Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!emba-news.uvm.edu!hal.emba.uvm.edu!wollman From: wollman@hal.emba.uvm.edu (Garrett Wollman) Subject: [386BSD] Fourth Release, i82586 Ethernet driver Message-ID: <1993Jan23.194050.635@uvm.edu> Sender: news@uvm.edu Organization: University of Vermont, EMBA Computer Facility Date: Sat, 23 Jan 1993 19:40:50 GMT Lines: 209 I am pleased to announce the release of the latest version of my i82586-based Ethernet device driver. This driver is currently known to work on AT&T EN100 and StarLAN 10 controllers, but the job of porting it to another card should be simple. >From the NEWS file: Changes from the Third Release of this driver: - Support for IP multicasting. - ieattach() correctly fills in its link-level address, so `netstat -i' gives useful information: ie0 1500 <Link>08.00.6a.81.14.15 391 0 328 0 0 - ieattach() also correctly fills in the link type information, so that if the hack is finally removed from if_attach(), it won't require changing. - More bugs hopefully eliminated. - More support for the StarLAN Fiber adapter (but it still doesn't work). ------------------------------------ The entire README file follows. README Fourth Release Intel i82586 Ethernet controller driver Copyright 1992, Garrett A. Wollman Copyright 1992, University of Vermont and State Agricultural College. See permission notice at end. INTRODUCTION This package consists of a driver for the Intel high-performance 8-/16-bit LAN controller, the i82586. The mode in which it currently operates is known to be correct for a standard DIX version 2.0 Ethernet, but may not be correct for some other network systems, such as StarLAN. The only network hardware currently supported is the AT&T EN100 NAU, operating in Ethernet mode, but the software was designed to allow support for other controllers to be easily integrated; indeed, only three functions need to be written in order for other standard Ethernet cards based on this controller to work. (The Clarkson Packet Drivers should show you what needs to be done.) The package as it stands does not support trailers. I see no particularly good reason for it to do so, since no modern network hardware emits such ugly packets. Eventually, I will try to support Paul Tsuchiya's PIP in addition to IP, NS, and 802.2. INSTALLATION To install this driver, you will first need to add the line if_ie.c optional ie device-driver to your /sys/i386/conf/files.i386 file. Once this is done, you should add a configuration file entry similar to the one included in my configuration file, TSORNIN. Then re-run `config', `make depend', and `make'. With luck, you will have a fully-functioning kernel with a network interface called `ie0'. (You should be able to configure more than one, but I've never tried this myself.) You can then add ifconfig ie0 inet my-address netmask my-netmask broadcast my-broadcast to your /etc/netstart, and away we go! PERFORMANCE Well, to be quite honest, performance was not one of my major goals. Indeed, I expect transmit to be quite a dog, since I only queue up a single transmit command. However, receive performance should be quite improved from the previous version (which died on large packets anyway), as the new version takes note of the fact that most packets are relatively small, and so uses a received frame area consisting of 32 received frame descriptors (so a maximum of 32 frames can be received while waiting for interrupt service) and 32 256-byte receive buffers. The driver itself also takes pains to free up un-needed receiver resources as soon as possible, to reduce the number of interrupts which must be processed. (The device interrupt routine also polls the 586 status register to keep immediate turnarounds down to a minimum.) I tested the TCP performance of my machine, tsornin, against sal, an SGI 4D/210S (which used to be a 220, 230, and 240). First, to get a baseline, I tested the loopback interfaces: For tsornin: ------------------------------------ ttcp-r: socket ttcp-r: accept from 127.0.0.1 ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: 16777216 bytes in 127.32 real seconds = 128.69 KB/sec +++ ttcp-r: 4997 I/O calls, msec/call = 26.09, calls/sec = 39.25 ttcp-r: 0.1user 38.1sys 2:07real 30% 0i+0d 0maxrss 0+0pf 156+4719csw ------------------------------------ For sal: ------------------------------------ ttcp-r: socket ttcp-r: accept from 127.0.0.1 ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: 16777216 bytes in 14.68 real seconds = 1116.02 KB/sec +++ ttcp-r: 2049 I/O calls, msec/call = 7.34, calls/sec = 139.57 ttcp-r: 0.0user 2.3sys 0:14real 15% 220maxrss 0+0pf 14+966csw ------------------------------------ The next test measures tsornin's receiver; this includes one cisco router hop: ------------------------------------ ttcp-r: socket ttcp-r: accept from 132.198.3.22 ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: 16777216 bytes in 134.31 real seconds = 121.99 KB/sec +++ ttcp-r: 16777216 bytes in 23.83 CPU seconds = 687.54 KB/cpu sec ttcp-r: 4123 I/O calls, msec/call = 33.36, calls/sec = 30.70 ttcp-r: 0.1user 23.7sys 2:14real 17% 0i+0d 0maxrss 0+0pf 4116+166csw ttcp-r: buffer address 0xc000 ------------------------------------ Finally, tsornin's transmitter (and, of course, also sal's receiver), still one hop: ------------------------------------ ttcp-r: socket ttcp-r: accept from 132.198.4.5 ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: 16777216 bytes in 101.18 real seconds = 161.93 KB/sec +++ ttcp-r: 16340 I/O calls, msec/call = 6.34, calls/sec = 161.49 ttcp-r: 0.1user 7.4sys 1:41real 7% 220maxrss 0+0pf 16334+32csw ------------------------------------ ACKNOWLEDGEMENTS This driver would not have been possible without the help of several individuals: - The authors of the Clarkson Packet Drivers - Terry from Novell - Somebody from Labtam whose name I've forgotten - Steve Ackerman for lending me a copy of his i82596 manual - Dr. Gary Barbour for not complaining about the amount of time I spent making this work right. - The United States Postal Service, for losing our order to Intel for a '586 manual. I would appreciate it if any new additions or extensions of this driver are communicated directly with me, rather than letting a mish-mash of different versions float about. CONTACTING THE AUTHOR You can contact me via electronic mail (preferred) as <Garrett.Wollman@UVM.EDU>. You can send paper mail to me at 127 Saint Paul Street #218, Burlington, VT 05401. COPYING Here are the conditions attached to this software: Copyright (c) 1992, University of Vermont and State Agricultural College. Copyright (c) 1992, Garrett A. Wollman. Portions: Copyright (c) 1990, 1991, William F. Jolitz Copyright (c) 1990, The Regents of the University of California All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman, by William F. Jolitz, by the University of California, Berkeley, by Lawrence Berkeley Laboratory, and its contributors. 4. Neither the names of the Universities nor the names of the authors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY OR AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant