From owner-freebsd-hardware@FreeBSD.ORG Tue May 6 11:42:48 2003 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66ECC37B401 for ; Tue, 6 May 2003 11:42:48 -0700 (PDT) Received: from mail.via.net (mail.via.net [209.81.9.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FD0F43F85 for ; Tue, 6 May 2003 11:42:45 -0700 (PDT) (envelope-from joe@via.net) Received: from [209.81.27.5] (host5.islandsw.com [209.81.27.5] (may be forged)) by mail.via.net (8.12.8/8.12.7) with ESMTP id h46If07D021963; Tue, 6 May 2003 11:41:00 -0700 (PDT) (envelope-from joe@via.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 06 May 2003 11:42:39 -0700 From: joe mcguckin To: "Jin Guojun [NCS]" , "Simon L. Nielsen" Message-ID: In-Reply-To: <3EB7FE5A.4FB0CC6B@lbl.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: hardware@freebsd.org Subject: Re: Intel GigE and copper PHY supported? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 18:42:48 -0000 We expect to push only 30 or 40 Mbits through it, so performance probably won't be an issue. We're using a GigE interface because that's the only port available on the ethernet switch we have to connect to. joe On 5/6/03 11:26 AM, "Jin Guojun [NCS]" wrote: > "Simon L. Nielsen" wrote: > >> On 2003.05.06 10:07:03 -0700, Jin Guojun [NCS] wrote: >>> joe mcguckin wrote: >>> >>>> I'd like to use the TYAN Trinity GC-SL motherboard with on-board GigE >>>> (copper). Does anyone know if this is supported? Has anyone used this board >>>> with 4.X? >>>> >>>> Thanks, >>> >>> Do not have direct use of this motherboard. We have some similar M/Bs >>> from SuperMicro (same chipset and same GigE NICs). >>> >>> General M/B performance is good. The GigE is not too pleasure. >>> The Incoming TCP is about 350 Mb/s, and out going TCP is only 270, >>> which is limited by interrupt (98% CPU -- 2.8 GHz -- used for interrupt). >>> Either the driver or the Intel NIC is not functioning properly, but we do >>> not >>> have time to investigate. >> >> If this the chips a using the em(4) driver you can try turning on >> interrupt coalation (or whatever Intel calls it). It can (AFAIR) only be >> done by modifying sys/dev/em/if_em.h. Just note the warning about why it >> was disabled. >> >> -- >> Simon L. Nielsen > > The Tx interrupt coalescing in if_em.h in 4.8-RELEASE is enabled to 64 * 1.024 > us: > /* > * TxIntDelay > * Valid Range: 0-65535 (0=off) > * Default Value: 64 > * This value delays the generation of transmit interrupts in units of > * 1.024 microseconds. Transmit interrupt reduction can improve CPU > * efficiency if properly tuned for specific network traffic. If the > * system is reporting dropped transmits, this value may be set too high > * causing the driver to run out of available transmit descriptors. > */ > #define EM_TIDV 64 > > If this is really set, then the chip is not designed correctly. In my design > experience, > the Tx interrupt can only be generated after Tx queue is empty. > The Tx interrupt is generated immediately if TIDV = 0, > or wait for TIDV * 1.024 us. > > If the driver can feed the device enough data (also recycling the used > buffers), > Tx interrupt should never happen. This is different from Rx interrupt. > > Two things can happen here, either the kernel does not provide enough data > to the NIC, or the NIC generates interrupts anyway after TIDV regardless > if the data queue is not empty. If it is the later case, I would blame Intel. > We also have the profermance issue on their 10Gb/s NIC, and we are still > investigating what is the problem. > > -Jin >