Date: Wed, 14 Dec 2011 16:23:08 -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: <20111215002308.GF11426@michelle.cdnetworks.com> In-Reply-To: <20111214232206.GE11426@michelle.cdnetworks.com> References: <4EE8FA10.8090502@netfence.it> <20111214195918.GC11426@michelle.cdnetworks.com> <4EE91275.3060808@netfence.it> <20111214213242.GD11426@michelle.cdnetworks.com> <20111214232206.GE11426@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Dec 14, 2011 at 03:22:06PM -0800, YongHyeon PYUN wrote:
> On Wed, Dec 14, 2011 at 01:32:42PM -0800, YongHyeon PYUN wrote:
> > On Wed, Dec 14, 2011 at 10:17:41PM +0100, Andrea Venturoli wrote:
> > > On 12/14/11 20:59, YongHyeon PYUN wrote:
> > >
> > > >AFAIK the firmware of controller has no known TSO issue so it
> > > >indicates a bug in driver.
> > > >What makes me wonder is ICMP ECHO packet should not be affected by
> > > >TSO and I have no clue at this moment.
> > >
> > > I wasn't talking about ICMP ECHO.
> > >
> > > What happened was:
> > > a) the client connected to my server, advertising a TCP MSS of X;
> > > b) my server started sending with packets larger than X (possibly it
> > > misinterpreted MSS size???);
> > > c) an ICMP packet arrived, asking my server to send packets no larger
> > > than Y (I guess it was ignored);
> > > d) my server kept resending the same (too big) packets;
> > > e) it eventually reduced packet size, but it was still larger than Y;
> > > ...
> > >
> > > 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).
> >
> > > Of course this made a bell ring and removing TSO solved everything.
> > >
> > >
> > >
> > > >(Here, I assume you've
> > > >captured packets on receiver side since bpf sees packets before
> > > >hardware computes checksum.)
> > >
> > > Yes, although I don't have them anymore.
> > >
> > >
> > >
> > > >If you have a reliable way that reproduces the issue, let me know.
> > >
> > > I can turn TSO on again, save the packets and send them to you.
> > > I just hope nothing changes on the Internet in between the server and
> > > the client.
> > > Let me know if you need/want this and I'll arrange in the next few days.
> > >
> >
> > Let me know MSS of both client and server.
> > Is simple downloading from client to server is enough to trigger
> > the issue? Packet capture that shows the problem would be great to
> > know what's going on here.
> >
>
> 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.
--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fxp.tso.diff2"
Index: sys/dev/fxp/if_fxp.c
===================================================================
--- sys/dev/fxp/if_fxp.c (revision 228504)
+++ sys/dev/fxp/if_fxp.c (working copy)
@@ -1454,7 +1454,7 @@
return (ENOBUFS);
}
tcp = (struct tcphdr *)(mtod(m, char *) + poff);
- m = m_pullup(m, poff + sizeof(struct tcphdr) + tcp->th_off);
+ m = m_pullup(m, poff + (tcp->th_off << 2));
if (m == NULL) {
*m_head = NULL;
return (ENOBUFS);
--rJwd6BRFiFCcLxzm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111215002308.GF11426>