Date: Mon, 7 Jan 2013 13:41:16 -0800 (PST) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Willem Jan Withagen <wjw@digiware.nl> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-net@freebsd.org, Adrian Chadd <adrian@freebsd.org>, David Christensen <davidch@freebsd.org>, linimon@freebsd.org Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver Message-ID: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <50EA8558.4010600@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Mon, 1/7/13, Willem Jan Withagen <wjw@digiware.nl> wrote: > From: Willem Jan Withagen <wjw@digiware.nl> > Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in = bxe driver > To: "Barney Cordoba" <barney_cordoba@yahoo.com> > Cc: "Garrett Cooper" <yanegomi@gmail.com>, freebsd-net@freebsd.org, "Adri= an Chadd" <adrian@freebsd.org>, "David Christensen" <davidch@freebsd.org>, = linimon@freebsd.org > Date: Monday, January 7, 2013, 3:20 AM > On 2013-01-05 16:17, Barney Cordoba > wrote: > >=20 > >=20 > > --- On Fri, 1/4/13, Willem Jan Withagen <wjw@digiware.nl> > wrote: > >=20 > >> From: Willem Jan Withagen <wjw@digiware.nl> > >> Subject: Re: kern/174851: [bxe] [patch] UDP > checksum offload is wrong in bxe driver > >> To: "Barney Cordoba" <barney_cordoba@yahoo.com> > >> Cc: "Garrett Cooper" <yanegomi@gmail.com>, > freebsd-net@freebsd.org, > "Adrian Chadd" <adrian@freebsd.org>, > "David Christensen" <davidch@freebsd.org>, > linimon@freebsd.org > >> Date: Friday, January 4, 2013, 9:41 AM > >> On 2013-01-01 0:04, Barney Cordoba > >> wrote: > >> > >>> The statement above "assumes" that there is a > benefit. > >> voIP packets=20 > >>> are short, so the benefit of offloading is > reduced. > >> There is some > >>> delay added by the hardware, and there are cpu > cycles > >> used in managing > >>> the offload code. So those operations not only > muddy > >> the code, > >>> but they may not be faster than simply doing > the > >> checksum on a much, much > >>> faster cpu. > >> > >> Forgoing all the discussions on performance and > possible > >> penalties in > >> drivers..... > >> > >> I think there is a large set of UDP streams (and > growing) > >> that do use > >> larger packets. > >> > >> The video streaming we did used a size of > header(14)+7*188, > >> which is the > >> max number of MPEG packet to fit into anything with > an MTU > >> < 1500. > >> > >> Receiving those on small embedded devices which can > do HW > >> check-summing > >> is very beneficial there. > >> On the large servers we would generate up to 5Gbit > of > >> outgoing streams. > >> I'm sure that offloading UDP checks would be an > advantage as > >> well. > >> (They did run mainly Linux, but FreeBSD would also > work) > >> > >> Unfortunately most of the infrastructure has been > taken > >> down, so it is > >> no longer possible to verify any of the > assumptions. > >> > >> --WjW > >=20 > > If you haven't benchmarked it, then you're just > guessing. That's my point. > >=20 > > Its like SMP in freeBSD 4. People bought big, honking > machines and the > > big expensive machines were slower than a single core > system at less than > > half the price. Just because something sounds better > doesn't mean that it is better. >=20 > I completely agree.... >=20 > Dutch proverb goes: > =A0=A0=A0 "To measure is to know" > Which was the subtitle of my graduation report, and my > professional > motto when working as a systems-architect.... >=20 > That's why it is sad that the system is no longer up and > running, > because a 0-order check would be no more that 1 ifconfig > would have made > a difference. >=20 > But that is all water under the bridge. >=20 > --WjW You can't really benchmark on a live network; you need a control. It's easy enough to generate controlled UDP streams. And of course every NIC would be a new deal. I'm sure that UDP offload is a checklist feature and not something that the intels and broadcoms of the world do a lot of=20 performance testing for. BC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1357594876.61921.YahooMailClassic>