linux-mips
[Top] [All Lists]

Re: [2.4 PATCH] pcnet32.c - tx underflow error

To: Jun Sun <jsun@mvista.com>
Subject: Re: [2.4 PATCH] pcnet32.c - tx underflow error
From: Jason Gunthorpe <jgg@debian.org>
Date: Wed, 10 Jul 2002 21:01:09 -0600 (MDT)
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-mips@oss.sgi.com, marcelo@conectiva.com.br
In-reply-to: <3D2CC891.1010506@mvista.com>
Reply-to: Jason Gunthorpe <jgg@debian.org>
Sender: owner-linux-mips@oss.sgi.com
On Wed, 10 Jul 2002, Jun Sun wrote:

> > Which slows the stuff down for people with real computers.
> 
> Contrary to what it might appear at first glance, it does not really.

I studied this sort of a problem to some extent on my system using a 8139
card..

Eventually it turned out to be poor arbitrartion between the PCI interface
and the CPU within the system controller. What happens is that the
memcpy from the skbuf to the packet ring in the driver ends up generating
a steady stream of very small writes that starve out PCI access. This is a
particular quirk of our system controller but I wouldn't be surprised if
other controllers had a simlar problem.

A good fix is to use a cached+flushed tx buffer which will lower the
observed DMA latency considerably.

There are some situations where a badly implemented PCI controller can
cause high enough latency if other devices are trying to use the bus, it
depends on how much the interface can burst and where the low watermark is
on the ethernet card. Most scenarios are unlikely though IMHO. 

If you have access to a PCI bus tracer you can determine where the problem
lies pretty quickly. 

> The delay itself is small (should be < 100us typically).  So there is no 

Actually it should be << 30us on an unloaded system. Measurements I've
done on my box are about 13us for a 8139 to read a 1.5K pkt over PCI.

Jason



<Prev in Thread] Current Thread [Next in Thread>