From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 00:09:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B391065698 for ; Tue, 12 Jan 2010 00:09:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9E78FC2B for ; Tue, 12 Jan 2010 00:09:51 +0000 (UTC) Received: by qyk41 with SMTP id 41so10636628qyk.29 for ; Mon, 11 Jan 2010 16:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=s5GSae0q3qpU3TzEjyABk29AJJvCqgYHCZAQacYPSW4=; b=txnHCTMlfv1eDvraynztmRzoIZLEr7WzgbgkYBT1cSg0k72umAssTH+HV3H/v8FuHS FDIxXgjYBJ3ZHgMoRjeKl07+irnFm2yn7oHodwFCBPEANUulWdSlxgmjgfsSKGmsX4d1 OIOEmCVUoZve0GMSeZHytPRkl3x0+OzzjK7fQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=KFy8iNvwEdnXGud80gJr0g7ALwWXfeBnivTrURne1i57N9JxTCRpLoTWKwGNGqVSwX +fm1WBNPIFnV5PLBETaY8FNskq0QsNV5iWe0ms4n5SjvC07Dv4S2c8ma1yQlkZ2rjc+X I99dLOcLqg8sdN+vqAi6Zw69t60WrCa84VMFM= Received: by 10.224.108.5 with SMTP id d5mr17078648qap.294.1263254983955; Mon, 11 Jan 2010 16:09:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 26sm3066098qwa.0.2010.01.11.16.09.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 16:09:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 16:08:59 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 16:08:59 -0800 To: David Ehrmann Message-ID: <20100112000859.GD1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4BB679.2060500@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 00:09:52 -0000 On Mon, Jan 11, 2010 at 03:38:33PM -0800, David Ehrmann wrote: > Pyun YongHyeon wrote: > >If receiver drops TX UDP frame sent by vge(4) would you try > >disabling TX checksum offloading of vge(4)? If packet drop happens > >only with UDP frames it could be checksum offload bug. Does your > >controller is VT6130(PCIe)? > > > > First, netstat before and after the test: > > share2# netstat -I vge0 -d > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll Drop > vge0 1500 00:40:63:xx:xx:xx 38940717 0 0 > 55913584 0 0 0 > vge0 1500 10.0.0.0/22 share2 38886994 - - > 55898223 - - - > share2# netstat -I vge0 -d > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll Drop > vge0 1500 00:40:63:xx:xx:xx 38942065 0 0 > 55914869 0 0 0 > vge0 1500 10.0.0.0/22 share2 38888320 - - > 55899491 - - - > > The error counters were uninteresting. Here's what the internal > counters said, but they weren't very interesting, either: > > http://pastebin.com/m20114095 > Ok, it indicates there are no FIFO overrun or no buf condition occurred in controller. > I ran the test, again, and had tcpdump capture the packets (on the host > with the vge interface). > > tcpdump -i vge0 -w dump.cap -K -s 0 host 10.0.1.2 > > When I opened it up in Wireshark, it's reporting that the outgoing UDP > checksums are incorrect; they're always 0x1ae3. That said, maybe the Because bpf(4) see the frame before controller inserts checksum value it always reports incorrect checksum. It's normal for TX checksum offload capable controller. In order to verify the hardware assisted checksum you should check that on receiver side. If the checksum was invalid, receiver dropped them. See "netstat -s | grep bad" on receiver host. > checksums are done in hardware AFTER tcpdump sees them. > > I set net.inet.udp.checksum to 0. The bad checksums are gone, but I > still see dropped packets. > This doesn't disable TX checksum offload of driver. Instead use #ifconfig vge0 -txcsum > It's on the motherboard, probably wired directly to a PCI-E connection, > but yes, it is a VT6130. Show me "pciconf -lcv" output.