From owner-freebsd-net@FreeBSD.ORG Wed Dec 30 20:30:08 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778DA106568B for ; Wed, 30 Dec 2009 20:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0BF8FC18 for ; Wed, 30 Dec 2009 20:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBUKU54F012803 for ; Wed, 30 Dec 2009 20:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBUKU5eA012796; Wed, 30 Dec 2009 20:30:05 GMT (envelope-from gnats) Date: Wed, 30 Dec 2009 20:30:05 GMT Message-Id: <200912302030.nBUKU5eA012796@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2009 20:30:08 -0000 The following reply was made to PR kern/141843; it has been noted by GNATS. From: Pyun YongHyeon To: Dennis Yusupoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Date: Wed, 30 Dec 2009 12:20:14 -0800 On Wed, Dec 30, 2009 at 01:34:30PM +0300, Dennis Yusupoff wrote: > 29.12.2009 21:51, Pyun YongHyeon ?????: > > On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon@freebsd.org wrote: > > > >> Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > >> New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets > >> > >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net > >> Responsible-Changed-By: linimon > >> Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009 > >> Responsible-Changed-Why: > >> Over to maintainer(s). > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 > >> > > I'm not sure whether you're seeing one of edge case of em(4)/igb(4) > > checksum offload issue. Personally I couldn't reproduce the issue > > but I guess the checksum offload/TSO handling might cause > > unexpected result. If you disable Tx checksum offload or TSO em(4) > > work as expected, right? > Not exactly. > Only checksum offload gives this issue, TSO on/off doesn't matter. > By the way, we checked UDP also and found something interested. > For it, we run echo service on server ("|echo dgram udp wait > root internal|" in //etc/inetd.conf/) and send strings by "|nc -4 -u > server 7|" from client. > So...UDP works fine before, while and after "ifconfig vlanX vlan X > vlandev em0" command given at server. And the most interesting things is > what while server "hangs" for TCP-connections, "establishing" UDP > connections between client and server...helps it to "unhang" TCP, so it > begins to works correctly. > > > If so, would you try the following patch > > and let me know whether it makes any difference? > > > > http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch > > > Doesn't help, same behavior. And moreover, UDP also doesn't "help" and > doesn't work so. > Sorry, that wasn't expected one. From your explanation above I think I found a possible cause of checksum offload issue of em(4). The issue was not I initially thought though. It seems the checksum offload context configured in em(4) was incorrectly reused even if a frame requires a new context as IP/TCP header length, checksum offload offset was changed. Setting up new context put more burden to hardware such that em(4) used to avoid new context setup as possible as it can. However it seems em(4) failed to compare all required field in the checksum offload context. Would you try the following patch again? http://people.freebsd.org/~yongari/em.csum_tso.20091230.patch > If you'd like, I could give you an access to this server via SSH, would you? Thanks for the offer. ATM I'm somewhat busy to address other driver issues. If the patch does not work and I find spare time I'll let you know.