Date: Fri, 21 Jul 1995 12:06:54 +0100 (BST) From: Paul Richards <paul@netcraft.co.uk> To: vak@cronyx.ru (Serge V.Vakulenko) Cc: hackers@FreeBSD.ORG, paul@isl.cf.ac.uk Subject: Re: [patch] if_lnc.c: support for PCI Lance Ethernet adapters added Message-ID: <199507211106.MAA02126@server.netcraft.co.uk> In-Reply-To: <Pine.BSF.3.91.950720194344.478A-100000@hanoi.net.kiae.su> from "Serge V.Vakulenko" at Jul 20, 95 07:47:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Serge V.Vakulenko who said
>
> This patch adds the support for PCI Ethernet cards,
> based on AMD 79C970 chip.
>
> Apply this patch, and add the following lines to the kernel config file:
>
> controller pci0
> device lnc0
>
> Enjoy!
>
> Some notes:
> 1. The Am79C970 chip has the same manufacturer id as the Am79C965 one.
> Probing for it was wrong in the original driver.
Yeah, the AMD docs are wrong and if you contact AMD they'll even tell
what the id should be and it's still wrong :-)
Every PCI chip I've seen uses the PCnet-32 ID as you've fuond out.
> 2. Loss of carrier message could happen too often on overloaded networks,
> it surely does not worth printing.
If you're getting these errors then something is wrong. I'm not planning
on removing that error message. The only error on lnc that possibly
needs thinking about is the heartbeat error since some cards don't
do the heartbeat test and you end up with a stream of such errors.
> 3. There was a question of unit number conflict with configured ISA/EISA/VLB
> cards, the PCI probe routine now skips all busy unit numbers.
>
> + switch (sc->nic.mem_mode) {
> + case DMA_FIXED: printf (", static DMA buffer mode"); break;
> + case DMA_MBUF: printf (", chained DMA buffers mode"); break;
> + case SHMEM: printf (", shared memory mode"); break;
> + }
You've misunderstood this slightly, the DMA_FIXED version uses pre-allocated
data buffers and copies the packets to/from the mbuf chains into
these buffers. The lance's ring descriptors then point to these
data buffers. The DMA_MBUF doesn't, it places a pointer to each
individual mbuf of a chain into a single ring descriptors, thus saving
the copy operation since the lance DMA's the packet straight into
the mbuf.
Since a single packet can be stored in more than 1 mbuf, more than one
ring descriptor is used per packet and so chaining has to be supported
by the driver. This is all experimental since I haven't seen a
noticeable performance improvement from using the DMA_MBUF option and
in fact that thread of the driver is pretty buggy and will cause
you lots of problems. I need to play around with it a lot more to see
if saving the copy is a bigger gain than is lost by using chaining.
There's lots of tradeofs to consider, chaning uses more bus/ethernet bandwidth.
On large packets, not copying saves cpu usage but on very small packets,
the code for handling chaining is probably more than that of a copy. I'd
guess that for large packets, throughput would likely be better when using
mbufs but if you get lots of small packets then it could be worse. It
may depend on your particular usage. In any case, this is all fun stuff
to look into sometime in the future when I get time to really work on it
properly. For now the DMA_FIXED code works well and is what the driver
is set up by default to do.
>
> +
> +/*
> + * PCI bus probe and attach routines for LANCE Ethernet controllers,
> + * by Serge V.Vakulenko, vak@cronyx.ru
> + */
I'll file this away and look at it all for 2.2. The pci code shouldn't
really go into the isa file. The bus specific probe code needs to be split
out and put in the proper place but this wouldn't be the only driver to
break the rules so....
--
Paul Richards, Bluebird Computer Systems. FreeBSD core team member.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507211106.MAA02126>