Hi Henrik, Sorry for the late reply. I was just back from vacation so I didn't read emails these days. The issue you raise in the thread is what we had been talking about (82541 performance regression), right? So I copy the key contents from the previous thread to make others clear about the current status.
In the previous thread, you mentioned that the fix of CR 6705005 e1000g LINK/ACT LED behaviour is not consistent with the EEPROM default may be the cause since it was ok after you removed the changes. The line e1000_cleanup_led(hw) you removed which actually calls e1000_cleanup_led_82541() It writes two registers at the initialization time. I'm checking to see the impacts. Regards, Miles Xu Henrik Johansson wrote: > Hello again, > > The problem is when the host is transferring data, receiving works fine. > > iperf shows 17% packet loss when sending UDP, when none when > receiving. Then bandwidth in TCP mode shows ~ 900Mbit when receiving > and ~ 350Kbit when sending. > > I have however isolated the problem to usr/src/uts/common/io/e1000g/ > e1000g_main.c revision 8178: > > 1369: (void) e1000_cleanup_led(hw); > > When this line is active the driver will lose packages, I have > compiled a test version of e1000g from snv_104 with this line > commented out and everything works fine. > > Regards > Henrik > > On Dec 18, 2008, at 5:00 AM, Min Miles Xu wrote: > > >> Henrik, >> Thanks for your update! The changes applied to e1000g in snv_98 seem >> to have little evidence. You can also try ftp or some UDP tests to >> help us identify the issue started to emerge on which version and on >> tx or rx side. >> >> Regards, >> >> Miles Xu >> >> Henrik Johansson wrote: >> >>> Hello Min, >>> >>> I did a quick tests and it seems that snv_97 does not have this >>> problem but snv_98 does. >>> >>> snv_97 did not lose any of 600 ICMP packages while snv_98 loses 1-5%. >>> >>> I have had limited time to try this today, I can probably do some >>> more tests tomorrow. >>> >>> Regards >>> Henrik >>> >>> >>> On Dec 17, 2008, at 5:06 AM, Min Miles Xu wrote: >>> >>> >>> >>>> Hi Henrik, >>>> Thanks for the information. I notice you are also using 82541. >>>> The issue sounds like a chip specific one. >>>> I just reviewed all the recent putbacked CR before snv_104 of >>>> e1000g. >>>> >>>> 6713032 e1000g port hang, no xmit, no recv >>>> 6767201 e1000g default_mtu does not coincide with >>>> max_frame_size on some chipsets when set via e1000g.conf >>>> PSARC 2008/608 brussels property permissions >>>> 6723890 ndd interface donesn't report properties' read/write >>>> capacities correctly after CR 6667363 >>>> >>>> was put back in snv_104, which should have no impact to 82541. >>>> >>>> 6727113 e1000g performance regression is observed with large >>>> connection and packet size if LSO is enabled >>>> 6756917 LSO is not enabled on some e1000g chips >>>> >>>> was put back in snv_103, which should have no impact to 82541. >>>> >>>> 6644298 some DLPI test cases fail in DomU when trying to >>>> receive in promiscuous and/or multicast mode >>>> PSARC 2008/382 Fast Reboot >>>> 6714038 Fast Reboot support for x86 platforms >>>> >>>> was put back in snv_100. >>>> >>>> 6666998 Add support for ICH10 in e1000g driver >>>> 6709230 Requesting driver support in e1000g for new Intel(R) >>>> single port MAC/PHY NIC >>>> >>>> was put back in snv_99. >>>> >>>> 6705005 e1000g LINK/ACT LED behaviour is not consistent with >>>> the EEPROM default >>>> 6738552 e1000g rx_lock is not initialized and destroyed in >>>> the code >>>> 6634746 e1000g is missing lint target in Makefile >>>> >>>> was put back in snv_98. >>>> >>>> Since I don't have such type of chip on hand, could you do me a >>>> favor to identify in which version the problem started to emerge? >>>> >>>> >>>> Thanks, >>>> >>>> Miles Xu >>>> Henrik Johansson wrote: > Hello all, > > I am having trouble with transmit performance on one of my Nevada > boxes, receiving works fine and has acceptable performance for a > gigabit network, but transmitting data is several times slower. > > The machine that has this problem is a snv_104 box with an e1000g > (intel 82541) interface. I have backed out what I think is the bug > previously discussed in the e1000g driver for the 82541 chipset (and > the performance is not a few hundred megabit and not kilobits) > > Receiving data on the affected machine from a Mac or a 2008.11 host > gives me ~ 850MBit/s. Sending data to ether of the other hosts gives > me about 300MBit/s. > > I tested to boot another OS from a live CD on this host and it gave me > at least 650MBit/s when sending data. > > These tests are mede with iperf, but i noticed the problem when > transferring files from the host. > > I have tried to tone some TCP parameters but with no luck > (tcp_cwnd_max, tcp_xmit_hiwat, tcp_recv_hiwat) > > Is this another chips specific bug with the 1000g driver or is there > something else I am missing? It works as I said fine on a snv_101 with > the 1000g driver but with another chip. > > The host is a dual core AMD athlon @ 2.7GHz so it should not have any > trouble handling the load. > > Suggestions on where to look are welcome, thanks. > > Henrik Johansson > http://sparcv9.blogspot.com > _______________________________________________ > networking-discuss mailing list > [email protected] _______________________________________________ networking-discuss mailing list [email protected]
