From owner-freebsd-hardware@FreeBSD.ORG Tue May 6 11:24:22 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 B682237B401 for ; Tue, 6 May 2003 11:24:22 -0700 (PDT) Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88C0743FAF for ; Tue, 6 May 2003 11:24:21 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Received: from lbl.gov (localhost.pacbell.net [127.0.0.1]) ESMTP id h46IQYZu000455; Tue, 6 May 2003 11:26:35 -0700 (PDT) (envelope-from j_guojun@lbl.gov) Sender: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net Message-ID: <3EB7FE5A.4FB0CC6B@lbl.gov> Date: Tue, 06 May 2003 11:26:34 -0700 From: "Jin Guojun [NCS]" X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386) X-Accept-Language: zh, zh-CN, en-US, en MIME-Version: 1.0 To: "Simon L. Nielsen" References: <3EB7EBB6.3038C32E@lbl.gov> <20030506172523.GE428@nitro.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: joe mcguckin 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:24:23 -0000 "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