From owner-freebsd-net@FreeBSD.ORG Mon Jan 7 23:29:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66265B27; Mon, 7 Jan 2013 23:29:02 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id C620FCF5; Mon, 7 Jan 2013 23:29:01 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 47DEA153434; Tue, 8 Jan 2013 00:28:59 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-4u9muI6643; Tue, 8 Jan 2013 00:28:58 +0100 (CET) Received: from [192.168.10.120] (10G [192.168.10.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 36616153433; Tue, 8 Jan 2013 00:28:58 +0100 (CET) References: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1357594876.61921.YahooMailClassic@web121603.mail.ne1.yahoo.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Willem Jan Withagen Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver Date: Tue, 8 Jan 2013 00:29:05 +0100 To: Barney Cordoba Cc: Garrett Cooper , "freebsd-net@freebsd.org" , Adrian Chadd , David Christensen , "linimon@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 23:29:02 -0000 Op 7 jan. 2013 om 22:41 heeft Barney Cordoba het v= olgende geschreven: >=20 >=20 > --- On Mon, 1/7/13, Willem Jan Withagen wrote: >=20 >> From: Willem Jan Withagen >> Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in b= xe driver >> To: "Barney Cordoba" >> Cc: "Garrett Cooper" , freebsd-net@freebsd.org, "Adri= an Chadd" , "David Christensen" , 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 >> wrote: >>>=20 >>>> From: Willem Jan Withagen >>>> Subject: Re: kern/174851: [bxe] [patch] UDP >> checksum offload is wrong in bxe driver >>>> To: "Barney Cordoba" >>>> Cc: "Garrett Cooper" , >> freebsd-net@freebsd.org, >> "Adrian Chadd" , >> "David Christensen" , >> 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=