kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver

[Willem Jan Withagen]

Op 7 jan. 2013 om 22:41 heeft Barney Cordoba <barney_cordoba at yahoo.com> het volgende geschreven:

> 
> 
> --- On Mon, 1/7/13, Willem Jan Withagen <wjw at digiware.nl> wrote:
> 
>> From: Willem Jan Withagen <wjw at digiware.nl>
>> Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver
>> To: "Barney Cordoba" <barney_cordoba at yahoo.com>
>> Cc: "Garrett Cooper" <yanegomi at gmail.com>, freebsd-net at freebsd.org, "Adrian Chadd" <adrian at freebsd.org>, "David Christensen" <davidch at freebsd.org>, linimon at 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 <wjw at digiware.nl>
>> wrote:
>>> 
>>>> From: Willem Jan Withagen <wjw at digiware.nl>
>>>> Subject: Re: kern/174851: [bxe] [patch] UDP
>> checksum offload is wrong in bxe driver
>>>> To: "Barney Cordoba" <barney_cordoba at yahoo.com>
>>>> Cc: "Garrett Cooper" <yanegomi at gmail.com>,
>> freebsd-net at freebsd.org,
>> "Adrian Chadd" <adrian at freebsd.org>,
>> "David Christensen" <davidch at freebsd.org>,
>> linimon at 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.

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.
> 


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 routers.

And don't get me started on fragmented UDP, that is like running the lottery.

--WjW