--- On Mon, 1/7/13, Willem Jan Withagen <w...@digiware.nl> wrote:
> From: Willem Jan Withagen <w...@digiware.nl> > Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe > driver > To: "Barney Cordoba" <barney_cord...@yahoo.com> > Cc: "Garrett Cooper" <yaneg...@gmail.com>, freebsd-net@freebsd.org, "Adrian > Chadd" <adr...@freebsd.org>, "David Christensen" <davi...@freebsd.org>, > lini...@freebsd.org > Date: Monday, January 7, 2013, 3:20 AM > On 2013-01-05 16:17, Barney Cordoba > wrote: > > > > > > --- On Fri, 1/4/13, Willem Jan Withagen <w...@digiware.nl> > wrote: > > > >> From: Willem Jan Withagen <w...@digiware.nl> > >> Subject: Re: kern/174851: [bxe] [patch] UDP > checksum offload is wrong in bxe driver > >> To: "Barney Cordoba" <barney_cord...@yahoo.com> > >> Cc: "Garrett Cooper" <yaneg...@gmail.com>, > freebsd-net@freebsd.org, > "Adrian Chadd" <adr...@freebsd.org>, > "David Christensen" <davi...@freebsd.org>, > lini...@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 > >>> 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 > > > > If you haven't benchmarked it, then you're just > guessing. That's my point. > > > > 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. > > I completely agree.... > > Dutch proverb goes: > "To measure is to know" > Which was the subtitle of my graduation report, and my > professional > motto when working as a systems-architect.... > > 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. > > But that is all water under the bridge. > > --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 performance testing for. BC _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
