em interface slow down on 8.0R

Pyun YongHyeon pyunyh at gmail.com
Wed Jan 27 00:46:50 UTC 2010


On Tue, Jan 26, 2010 at 12:36:22PM -0800, Jack Vogel wrote:
> Great, if you can get the changes to me quickly I'd like to incorporate
> them.
> 

Unfortunately I couldn't reproduce it on my box. I've tested both
IPv4 and IPv6 at the same time with netperf and it worked as
expected.
Reading the code also indicates the patch wouldn't break IPv6
traffic as CSUM_OFFLOAD is not set by upper stack.
Are you using any special configurations for testing?

> BTW, I have merged your igb changes into my code and its very stable, should
> see that checked in for 7.3 shortly.
> 

That's great! Thank you.

> Thanks for your hard work Pyun!
> 

No problem.

> Jack
> 
> 
> On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon <pyunyh at gmail.com> wrote:
> 
> > On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote:
> > > Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an
> > > interface,
> > > then netperf runs over both, I don't know the internal details but I
> > assume
> > > both TCP
> > > and UDP are going over ipv6.
> > >
> > > Prior to your change there is IPv6 handling code in the tx checksum
> > > routine,  so I
> > > assume the hardware offload for that works. With your patch if I disable
> > > TXCSUM
> > > on the interface then it will work... but before your change it works
> > with
> > > that on.
> > >
> > > So, am I missing something?
> > >
> >
> > Hmm, then I guess there is bug in the patch. Apparently upper stack
> > already computed checksum for IPv6 so the patch should not try to
> > offload IPv6 traffic again. I'll see the patch again.
> > Thanks for valuable input. :-)
> >
> > > Cheers,
> > >
> > > Jack
> > >
> > >
> > > On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon <pyunyh at gmail.com>
> > wrote:
> > >
> > > > On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote:
> > > > > I've tried this patch, and it completely breaks IPv6 offloads, which
> > DO
> > > > work
> > > > > btw,
> > > > > our testers have a netperf stress test that does both ipv4 and ipv6,
> > and
> > > > > that test
> > > > > fails 100% after this change.
> > > > >
> > > > > I could go hacking at it myself but as its your code Pyun would you
> > like
> > > > to
> > > > > resolve this issue?
> > > > >
> > > >
> > > > I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD
> > > > does not have that capability yet. Do we already have that
> > > > capability? I vaguely remember there was an effort to bring the
> > > > support in but I don't know current status. If we have the
> > > > capability I would have to update all other drivers that can do
> > > > IPv6 checksum offloading/TSO for IPv6.
> > > >
> > > > > Regards,
> > > > >
> > > > > Jack
> > > > >
> > > > >
> > > > > On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel <jfvogel at gmail.com>
> > wrote:
> > > > >
> > > > > > No, it hasn't, I need time to look it over and be convinced of what
> > he
> > > > was
> > > > > > doing.
> > > > > >
> > > > > > Jack
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers <ncrogers at gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> looks like the patch mentioned in kern/141843 has not been applied
> > to
> > > > the
> > > > > >> tree?
> > > > > >>
> > > > > >> On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers <ncrogers at gmail.com>
> > > > wrote:
> > > > > >>
> > > > > >> > Is it advisable to patch 8.0-RELEASE kernel sources with the
> > latest
> > > > > >> > (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like
> > there
> > > > are
> > > > > >> some
> > > > > >> > updates to the driver since 8.0-RELEASE that may fix some
> > problems?
> > > > > >> >
> > > > > >> >
> > > > > >> _______________________________________________
> > > > > >> freebsd-stable at freebsd.org mailing list
> > > > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > > >> To unsubscribe, send any mail to "
> > > > freebsd-stable-unsubscribe at freebsd.org"
> > > > > >>
> > > > > >
> > > > > >
> > > >
> >


More information about the freebsd-stable mailing list