Date: Sun, 25 Mar 2012 17:30:16 -0700 From: YongHyeon PYUN <pyunyh@gmail.com> To: Andreas Longwitz <longwitz@incore.de> Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode Message-ID: <20120326003016.GA1435@michelle.cdnetworks.com> In-Reply-To: <4F6DA161.9040408@incore.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120326003016.GA1435>