Date: Wed, 30 Dec 2009 20:30:05 GMT From: Pyun YongHyeon <pyunyh@gmail.com> To: freebsd-net@FreeBSD.org Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst MAC in TCP packets Message-ID: <200912302030.nBUKU5eA012796@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/141843; it has been noted by GNATS. From: Pyun YongHyeon <pyunyh@gmail.com> To: Dennis Yusupoff <dyr@smartspb.net> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912302030.nBUKU5eA012796>