From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 08:30:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D2F106566B for ; Sun, 25 Mar 2012 08:30:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 11FE18FC1A for ; Sun, 25 Mar 2012 08:30:25 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5168357pbc.13 for ; Sun, 25 Mar 2012 01:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/+xVaV7k8K5BTG7Pxuv0QxbBi+8cppaMI+Z4Nd9spc0=; b=WkZKcUNbgTHVAAsJnu6TsUq0oIWexRZhYD+1gX/stqvmLlx5/BpzOgJBU7dFq8ilym 6QPggfqkeIUmHe1yDiKoioF4eZ+bc9pvGxYHespF8oxeK/2OJNwcqPZiSme2KEKgcZin 0RHicLToBmkbtvBhkVZsca0fMJkuOCaWnAHIy0VZVUVualxwWiSToPZKAESrlf5x5uJ4 ZwjNFUkgYf9u7HLNyi7ZW9KenHBn/5W5ckhKcQstAhnb94if9N8TZ9YjSeWNzD2zTrbZ KvIGcrME9gZ31OIDZz89kRWli4ddq/Yai8thhQh/zpi9yUp6hHvu/OF57UX0vCV7Dz7I 7Msg== Received: by 10.68.197.194 with SMTP id iw2mr43442807pbc.26.1332664225692; Sun, 25 Mar 2012 01:30:25 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id e7sm9791951pbs.21.2012.03.25.01.30.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Mar 2012 01:30:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 25 Mar 2012 17:30:16 -0700 From: YongHyeon PYUN Date: Sun, 25 Mar 2012 17:30:16 -0700 To: Andreas Longwitz Message-ID: <20120326003016.GA1435@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> <20120313202559.GA3360@michelle.cdnetworks.com> <4F66646E.4080603@incore.de> <20120320041647.GE7518@michelle.cdnetworks.com> <4F6DA161.9040408@incore.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <4F6DA161.9040408@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 08:30:26 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 24, 2012 at 11:26:41AM +0100, Andreas Longwitz wrote: > YongHyeon PYUN wrote: > > > I didn't ever try NFS on i82550C. If it can't handle fragmented IP > > datagrams, it would also have failed netperf UDP stream test since > > all UDP datagrams are fragmented. > > Yes, you are right. The test needs to run more than 10 seconds to see > lost packets. Running > netperf -H host_with_fxp -t UDP_STREAM -l 30000 > gives without loading microcode on the fxp independent of polling: > > Socket Message Elapsed Messages > Size Size Time Okay Errors Throughput > bytes bytes secs # # 10^6bits/sec > > 9216 9216 30001.38 38972627 194368988 95.77 > 41600 30001.38 34293209 84.28 > > With microcode loaded no packets are lost. > Ok. > >> The test command > >> netperf -H host_with_fxp -t UDP_STREAM > >> gives nearly always the same output > >> > >> Socket Message Elapsed Messages > >> Size Size Time Okay Errors Throughput > >> bytes bytes secs # # 10^6bits/sec > >> > >> 9216 9216 10.00 13069 1515880 96.34 > >> 41600 10.00 13069 96.34 > >> > >> And this output did not considerably change for the test cases fxp-type > >> i82550C or i82550, microcode loaded or not and polling yes or no. > >> > >> But I can answer your question concerning the CPU Saver funktion on > >> i82550C and its a little suprise (for me). In all my tests without > >> polling I checked the irq's on host_with_fxp using "vmstat -i". The > >> result is that the CPU Saver feature of the microcode does not work on > >> i82250C and it works on i82250. On i82250C the value of > >> dev.fxp.0.bundle_max is irrelevant, the i82250C always needs ca. 91000 > >> irq's for the netperf test. The same number of irq's needs the i82250 > >> with bundle_max=1, but when I set bundle_max=6 (the default), then the > >> number of irq's for the same test goes down to 91000/7 = 13000. > > > > Thanks for the detailed information. This indicates the microcode > > for i82550C does not have bundling feature. > > Yes, but the microcode solves the stability problem for UDP streams, and > to load the microcode without side effects I need my "bzero-patch". > It seems there are differences between yours and mine. I disabled microcode loading for 82550 family since my 82550C didn't work after loading the code(Microcode loading works but it locked up after that). However it seems the microcode still has some valid usage for certain 82550 configuration. :-( > > By chance, did you > > ever update your controller firmware to newest one? I don't > > remember whether I also updated controller firmware for i82550C but > > I used to update several i82559 controllers for PXE. > > Thank you for this hint, I didn't know that the firmware in the > cantroller can be updated. All of my i82550C (= rev 0x0d) sit on a > (intel) motherboard of type SCB2S, all of my i82550 (= rev 0x0c) are > external cards. The following information I got with a DOS-Tool called > IBABUILD.exe. This tool supports the Intel boot Agent on the controller. > On the external cards this tool can update the Intel boot Agent software > and I found versions 3.0.03, 4.0.19 and the newest is 4.2.0.3. If I remember correctly there is another tool that updates EEPROM which may affect controller operation mode. Unfortunately I don't remember details at the moment.(I don't heavily use fxp(4) controllers because it has lots of limitation and it's too tricky to work it without racing between hardware and driver. I just keep it to support fxp(4) for other users.) > But there never was any dependency between the version of the Intel boot > Agent software and microcode. For chips on the motherboard (LOM) the > tool does not show a version, but booting a server with PXE gives 4.0.17 > for the version of the Intel boot Agent software. It looks like this > software is only responsible for PXE and nothing else. > I've attached a patch which will show both compatibility and EEPROM ID word and allowed loading microcode for 82550 family. Let me know whether this patch works for you. I vaguely guess there are differences between LOM and non-LOM implementation(Mine is stand-alone PCI NIC). I would be able to selectively allow microcode loading after getting compatibility/EEPROM ID word. > > Regards > > Andreas Longwitz > --pf9I7BMVVzbSWLtt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fxp.82550.microcode.diff" Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 233418) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -194,7 +194,7 @@ { 0x1229, 0x08, 0, "Intel 82559 Pro/100 Ethernet" }, { 0x1229, 0x09, 0, "Intel 82559ER Pro/100 Ethernet" }, { 0x1229, 0x0c, 0, "Intel 82550 Pro/100 Ethernet" }, - { 0x1229, 0x0d, 0, "Intel 82550 Pro/100 Ethernet" }, + { 0x1229, 0x0d, 0, "Intel 82550C Pro/100 Ethernet" }, { 0x1229, 0x0e, 0, "Intel 82550 Pro/100 Ethernet" }, { 0x1229, 0x0f, 0, "Intel 82551 Pro/100 Ethernet" }, { 0x1229, 0x10, 0, "Intel 82551 Pro/100 Ethernet" }, @@ -525,6 +525,13 @@ sc->flags |= FXP_FLAG_WOLCAP; } + if (sc->revision == FXP_REV_82550 || sc->revision == FXP_REV_82550_C) { + fxp_read_eeprom(sc, &data, 3, 1); + device_printf(dev, "Compatibility word : 0X%04x\n", data); + fxp_read_eeprom(sc, &data, 10, 1); + device_printf(dev, "EEPROM ID word : 0X%04x\n", data); + } + /* Receiver lock-up workaround detection. */ if (sc->revision < FXP_REV_82558_A4) { fxp_read_eeprom(sc, &data, 3, 1); @@ -3014,10 +3021,8 @@ static uint32_t fxp_ucode_d101b0[] = D101_B0_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101ma[] = D101M_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101s[] = D101S_RCVBUNDLE_UCODE; -#ifdef notyet static uint32_t fxp_ucode_d102[] = D102_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d102c[] = D102_C_RCVBUNDLE_UCODE; -#endif static uint32_t fxp_ucode_d102e[] = D102_E_RCVBUNDLE_UCODE; #define UCODE(x) x, sizeof(x)/sizeof(uint32_t) @@ -3035,12 +3040,10 @@ D101M_CPUSAVER_DWORD, D101M_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82559S_A, UCODE(fxp_ucode_d101s), D101S_CPUSAVER_DWORD, D101S_CPUSAVER_BUNDLE_MAX_DWORD }, -#ifdef notyet { FXP_REV_82550, UCODE(fxp_ucode_d102), D102_B_CPUSAVER_DWORD, D102_B_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82550_C, UCODE(fxp_ucode_d102c), D102_C_CPUSAVER_DWORD, D102_C_CPUSAVER_BUNDLE_MAX_DWORD }, -#endif { FXP_REV_82551_F, UCODE(fxp_ucode_d102e), D102_E_CPUSAVER_DWORD, D102_E_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82551_10, UCODE(fxp_ucode_d102e), @@ -3087,6 +3090,7 @@ sc->tunable_int_delay, uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); sc->flags |= FXP_FLAG_UCODE; + bzero(cbp, FXP_TXCB_SZ); } #define FXP_SYSCTL_STAT_ADD(c, h, n, p, d) \ --pf9I7BMVVzbSWLtt--