Date: Fri, 10 Sep 2004 22:15:58 +0000 (GMT) From: wpaul@FreeBSD.ORG (Bill Paul) To: andre@freebsd.org (Andre Oppermann) Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc devd.conf src/sys/modules Makefilesrc/sys/modules/vge Makefile src/sys/dev/vge if_vge.c if_vgereg.hif_ Message-ID: <20040910221559.01AA216A4D1@hub.freebsd.org> In-Reply-To: <41421EEE.C3E12DA7@freebsd.org> from Andre Oppermann at "Sep 10, 2004 11:38:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Bill Paul wrote:
> >
> > wpaul 2004-09-10 20:57:46 UTC
> >
> > FreeBSD src repository
> >
> > Modified files:
> > etc devd.conf
> > sys/modules Makefile
> > sys/dev/mii miidevs
> > sys/conf files
> > sys/i386/conf GENERIC
> > sys/pc98/conf GENERIC
> > sys/amd64/conf GENERIC
> > usr.sbin/sysinstall devices.c
> > Added files:
> > sys/modules/vge Makefile
> > sys/dev/vge if_vge.c if_vgereg.h if_vgevar.h
> > sys/dev/mii ciphy.c ciphyreg.h
> > Log:
> > Add device driver support for the VIA Networking Technologies
> > VT6122 gigabit ethernet chip and integrated 10/100/1000 copper PHY.
> > The vge driver has been added to GENERIC for i386, pc98 and amd64,
> > but not to sparc or ia64 since I don't have the ability to test
> > it there. The vge(4) driver supports VLANs, checksum offload and
> > jumbo frames.
>
> You are my hero! I've got two of those cards (one 64bit PCI and one 32bit)
> gathering dust. The kernel recompile is on the way...
>
> How well designed is the VT6122? Is it good or more on the 'it works' side?
It's "ok." I only have a 33Mhz/32-bit PCI sample card. When I tested
it, I only got it up to about 540Mbps. I attribute some of this to
5.3-BETA3's (lack of) performance. :( I was only able to get about
120000 frames/sec transmit frame rate out of it, which disappointed
me. (It should be closer to 400000, especially on a dual PIII 1.2Ghz
system.)
There's supposed to be interrupt moderation support, but it's only
available in certain chip revs (newer than 0x10, I think). Getting it
to work is unreasonably tricky, so I didn't bother.
RX DMA descriptors _must_ be replentished 4 at a time, because the
chip apparently caches them 4 at a time. You won't notice this until
you get a "ran out of RX descriptors" condition, in which case the
chip's DMA logic can get oddly out of sync (once you re-enable the
RX ring, it will update the status words for descriptor (X) but put the
received packet data in the buffer attached to descriptor (X - 2)).
The irritating thing is this requirement is not documented in the
chip manual.
In order to achive the "fill in multiple descriptors, then issue just
one TX command to make the chip snarf them all" behavior which is
standard with most chips, you have to set a special 'queue' bit in
all descriptors, except the last one in a list that you want snarfed.
The logic to do this is a little awkward. The 'queue' bit is also
not documented in the manual.
I would put it in about the same class as the NatSemi DP83820,
except that it has an integrated PHY.
-Bill
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul@windriver.com | Wind River Systems
=============================================================================
<adamw> you're just BEGGING to face the moose
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040910221559.01AA216A4D1>