Date: Tue, 8 Jan 2013 00:29:05 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Barney Cordoba <barney_cordoba@yahoo.com> Cc: Garrett Cooper <yanegomi@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, David Christensen <davidch@freebsd.org>, "linimon@freebsd.org" <linimon@freebsd.org> Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver Message-ID: <FD1A7E18-1801-49F4-9DB7-28639F7F7747@digiware.nl> In-Reply-To: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> References: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Op 7 jan. 2013 om 22:41 heeft Barney Cordoba <barney_cordoba@yahoo.com> het v= olgende geschreven: >=20 >=20 > --- On Mon, 1/7/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 b= xe 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>, l= inimon@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: >>>>=20 >>>>> 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. >>>>=20 >>>> Forgoing all the discussions on performance and >> possible >>>> penalties in >>>> drivers..... >>>>=20 >>>> I think there is a large set of UDP streams (and >> growing) >>>> that do use >>>> larger packets. >>>>=20 >>>> 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. >>>>=20 >>>> 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) >>>>=20 >>>> Unfortunately most of the infrastructure has been >> taken >>>> down, so it is >>>> no longer possible to verify any of the >> assumptions. >>>>=20 >>>> --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: >> "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 >=20 > 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. We did have a 10gb test environment, as lab. That was what i ment when i said, too bad IT is no longer up and running. ATM i can't even get to the hardware. >=20 But you are right, UDP has always been the stepchild of the industry. I've seen some real bad router UDP implementations while testing consumer r= outers. And don't get me started on fragmented UDP, that is like running the lottery= . --WjW=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FD1A7E18-1801-49F4-9DB7-28639F7F7747>