Return to BSD News archive
Xref: sserve comp.os.386bsd.development:246 comp.os.386bsd.announce:13
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate!usenet
From: Garrett.Wollman@UVM.EDU (Garrett Wollman)
Newsgroups: comp.os.386bsd.development,comp.os.386bsd.announce
Subject: Fifth Release, if_ie.c Ethernet Driver, now available
Followup-To: comp.os.386bsd.development
Date: 19 Mar 1993 16:32:27 -0800
Organization: University of Vermont, EMBA Computer Facility
Lines: 223
Sender: cgd@agate.berkeley.edu
Approved: 386bsd-announce-request@agate.berkeley.edu
Message-ID: <1993Mar20.002332.2182@uvm.edu>
NNTP-Posting-Host: agate.berkeley.edu
The Fifth Release of my if_ie.c Ethernet driver is now available by
anonymous FTP to tsornin.emba.uvm.edu, as /386BSD/ie-driver.tar.Z.
Following is an extract from the NEWS file, and the contents of the
README file.
-GAWollman
------------------------------------
Changes from the Fourth Release of this driver:
- The `iestat' program is now included to unscramble the mass of
pointers and other strange objects in the kernel, printing the
entire ie_softc structure in human-readable form.
- Support for BPF and IP multicast routing.
- Driver now allocates all memory for a packet before reading the
packet. This means that for large packets we can allocate an mbuf
cluster which can hold the entire packet, rather than a long string
of mbufs. This saves needless copying in the kernel.
- Disabled watchdog timer. This could cause things to get really
screwed up if it happened while a packet was being received, since
the timers are called (eventually) from softclock() which runs at a
higher priority than our driver. Ack!
- Documentation changed to reflect the precise nature of this driver's
genericity.
- As always, more bugs eliminated. It may not actually be faster
(indeed, it may be slower). Experience from other users would be
most welcome.
------------------------------------
README
Fifth Release
Intel i82586 Ethernet controller driver
Copyright 1992-93, Garrett A. Wollman
Copyright 1992-93, 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, implemented in a dual-ported
memory mode such as the AT&T EN100. 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,
similar cards to be supported. (Get the Crynwyr Packet Driver system;
if the driver for your card uses i82586.inc, then support for it can
probably be implemented in this framework. Not all 586-based adapters
use this method, so some cards will remain permanently out of the
fold.)
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
(Note: I have not updated this section since the Second Release. Your
Mileage May Vary.)
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 (now Crynwyr) Packet Drivers
- Terry Lambert from Novell
- Mark Treacy from Labtam
- 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-93, University of Vermont and State Agricultural College.
Copyright (c) 1992-93, 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