From owner-freebsd-questions@FreeBSD.ORG Sun Mar 5 02:32:12 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A77716A420 for ; Sun, 5 Mar 2006 02:32:12 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1AE843D45 for ; Sun, 5 Mar 2006 02:32:11 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so918693wri for ; Sat, 04 Mar 2006 18:32:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fQ738++zs6lIAnMsWZRal5BOFZJU8wPHAgm0qNKNeaS3JNnPITLnc/l3uJixsxoH/zwzgIe+mN4aLdjqdkWs5ZV0C2auOvREombyIm1p64jybQPO+MkkvpvZsHPFc50am40LCAvCsM440tQ8ABW50vRAsav+Z7gcCOXSPcaaLxU= Received: by 10.54.82.17 with SMTP id f17mr3917158wrb; Sat, 04 Mar 2006 18:32:10 -0800 (PST) Received: by 10.54.113.12 with HTTP; Sat, 4 Mar 2006 18:32:10 -0800 (PST) Message-ID: <3aaaa3a0603041832v36e76180r@mail.gmail.com> Date: Sun, 5 Mar 2006 02:32:10 +0000 From: Chris To: "Igor Robul" In-Reply-To: <20060228115826.GA9278@sysadm.stc> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200602261627.27483.freebsda@fuckaround.org> <4401CE90.2080703@mac.com> <3aaaa3a0602261520y7a3e16dy@mail.gmail.com> <20060228065555.GA5040@panix.com> <20060228115826.GA9278@sysadm.stc> Cc: freebsd-questions@freebsd.org Subject: Re: rl0 discard oversize X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2006 02:32:12 -0000 On 28/02/06, Igor Robul wrote: > On Tue, Feb 28, 2006 at 01:55:56AM -0500, David Scheidt wrote: > > The RealTek cards supported by the rl(4) driver are trash. If you want= to > > write a better driver, knock yourself out. I'm sure Bill Paul won't > > mind. Keep in mind that there are other, better performing NICs > > available for the about same price. > Most RL8139 cards work fine in our company. Most Windows PCs have these > cards (slowly replaced by integrated NICs on new motherboards), also > some FreeBSD-based routers have these NICs. > _______________________________________________ Likewise fine here, the fact windows outperforms freebsd with realteks should be enough embarrasement to warrant a rewrite. A realtek 8139 can easily do full 100mbit with no packet loss but just uses higher cpu utilisation, also its not always easy to say to a datacentre swap the card for diff brand. I like freebsd a lot, but my most worrying thought is their attitude to low end hardware, alot of 486 and 586 class and low end 686 class machines fail to boot in 6.x and everytime this is brought up the hardware is blamed and advised to replace, great if you loaded with cash. The comparison with linux is they maintain support for old hardware. But I guess telling people their card is trash (when it isnt) is easier then rewriting a driver, I cant rewrite as I have no knowledge of coding. here is a quote from the linux 2.6 driver notes. "The 8139too driver is based almost entirely on the on the 8139 driver written by Donald Becker. It has a few operational changes, most of which are flawed or pointless. MMIO vs. PIO operation The 8139 is mapped to both PCI I/O and memory space. Using I/O space is traditional on x86 architectures, and most drivers are written to use this mode. However, using the memory space mapping (MMIO) is more efficient for isolated writes since these are stored in a write buffer and the processor can continue execution without waiting for the PCI operation to complete. An added advantage is the processors without native I/O operations avoid extra address space calculations. A problem with using this MMIO mode is that the 8139 has different access alignment restrictions with memory space, and the write buffer potentially changes the ordering of command writes and subsequent memory reads. The 8139too driver attempts to work around the latter problem by doing a read immediately following a register write. Not only does this completely eliminate the advantage of having a write buffer, it doubles the overhead over just using I/O operations! Added Spin-locks The 8139too adds spin-locks. However, as with so many of the 2.3 spin-locks, it added them without considering if they were actually needed. The only code with a potential conflict is when reading and writing MII registers. But the 8139too driver supports only the 8139, which has an internal transceiver that is directly accessed by registers reads. So no spin-lock is needed! The "rx_size" patch The 8139too driver adds a patch taken from the BSD driver. This patch claims to fix a bug in the Rx ring: when copying a packet into RAM, the length will be 0xfff0. But the BSD "bug" is an artifact of that driver trying to avoid PCI bus operations by guessing if a packet has arrived, rather than following the documented method of check the RxBufEmpty status. The BSD method is more efficient. Checking the next entry and guessing can potentially save one or two expensive PCI transactions per Rx packet. But (as they found out) it is prone to races and failure. The Linux driver never encounters this problem, but the BSD "bug fix" was blindly added anyway." I see they taken something from the bsd drivers but are the other optimisations mentioned in the bsd driver? Chris