From owner-freebsd-net@FreeBSD.ORG Sat Dec 17 12:46:59 2011 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 BD032106566C for ; Sat, 17 Dec 2011 12:46:59 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out7.libero.it (cp-out7.libero.it [212.52.84.107]) by mx1.freebsd.org (Postfix) with ESMTP id 39C9B8FC08 for ; Sat, 17 Dec 2011 12:46:59 +0000 (UTC) X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A0B0202.4EEC8F41.00F2,ss=1,re=0.000,fgs=0 X-libjamoibt: 1555 Received: from soth.ventu (151.41.159.94) by cp-out7.libero.it (8.5.133) id 4E9539DD096F2DDC; Sat, 17 Dec 2011 13:46:57 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.4) with ESMTP id pBHCklUm006849; Sat, 17 Dec 2011 13:46:48 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4EEC8F37.5030209@netfence.it> Date: Sat, 17 Dec 2011 13:46:47 +0100 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.2.24) Gecko/20111207 Thunderbird/3.1.16 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4EE8FA10.8090502@netfence.it> <20111214195918.GC11426@michelle.cdnetworks.com> <4EE91275.3060808@netfence.it> <20111214213242.GD11426@michelle.cdnetworks.com> <4EEA0153.5010305@netfence.it> <20111215221337.GA15187@michelle.cdnetworks.com> In-Reply-To: <20111215221337.GA15187@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.1.2.13 Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and TSO troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 12:46:59 -0000 On 12/15/11 23:13, YongHyeon PYUN wrote: >> 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. Still all bad counters at zero. >> 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. Thanks go to you! :-) > 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. Very interesting: I'm not using bridge on this host, but I'm using ipfw! Which rules are incompatible? Any pointer on this? I'm also using CARP, in case it could matter, but not on this interface. bye & Thanks av.