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

[Barney Cordoba]

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

BC