Date: Thu, 15 Dec 2011 14:13:37 -0800 From: YongHyeon PYUN <pyunyh@gmail.com> To: Andrea Venturoli <ml@netfence.it> Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and TSO troubles Message-ID: <20111215221337.GA15187@michelle.cdnetworks.com> In-Reply-To: <4EEA0153.5010305@netfence.it> References: <4EE8FA10.8090502@netfence.it> <20111214195918.GC11426@michelle.cdnetworks.com> <4EE91275.3060808@netfence.it> <20111214213242.GD11426@michelle.cdnetworks.com> <4EEA0153.5010305@netfence.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 15, 2011 at 03:16:51PM +0100, Andrea Venturoli wrote: > On 12/14/11 22:32, YongHyeon PYUN wrote: > > >>Wireshark showed some wrong checksums (I believe on the ICMP packet, but > >>I might remember wrong). > > > >You can check whether you received bad checksummed frames with > >netstat(1). > > I tried "netstat -ind", but it shows no Ierrs/Idrop/Oerrs/Odrop. > Use -s option which will show statistics for each network protocols. Search 'discarded for bad checksums' from the output. > > > > > >Is simple downloading from client to server is enough to trigger > >the issue? > > Yes and no. > Depending on where the client is located (on the Internet) and/or the > protocol used, I get either failures or ridicuolous performance (i.e. > 58-60kB/s without TSO vs. 1-2kB/s with TSO). > > > > > > >Packet capture that shows the problem would be great to > >know what's going on here. > > I'll send them to you privately. > > You'll see tso.dump and notso.dump: they are both from the same client > downloading the same (random) file (the file name was changed only to > prevent possible caching). > See notso.dump is perfect, while tso.dump shows a lot of potential problems. > Thanks. > > > > > >>Would you try attached patch and let me know it goes? > >Sorry, it seems extra pull up for TCP payload may not be required > >here. Try this instead. > > I see a little increase in performance (2-3kB/s instead of 1-2kB/s); > this might however well depend on external factors. Still it is very > different from what I'm get without TSO. > Thanks for testing. Based on dump file, I tried various MTU configuration and I was not able to reproduce it. By chance, are you using firewall(pf/ipfw/ipf) or bridge(4)? If I remember correctly some firewall rules are not compatible with TSO. For bridge, if one member of bridge does not support TSO, TSO should be disabled. > > > bye & Thanks > av. > > P.S. I can live well without TSO; I'm just doing this to let the > software improve. Go ahead only if *you* are interested. I do care driver stability so it would be great if I manage to address the issue. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111215221337.GA15187>