Date: Sun, 18 Sep 2011 18:05:33 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: jfv@freebsd.org, pyunyh@gmail.com, Hooman Fazaeli <fazaeli@sepehrs.com>, freebsd-hackers@freebsd.org Subject: Re: intel checksum offload Message-ID: <CACqU3MXSms9M-H9jj6zf5qWo05SLNCDBwDv%2B%2BmW5iTNjNLuKkA@mail.gmail.com> In-Reply-To: <20110918210647.GA8930@onelab2.iet.unipi.it> References: <4E744BCE.7060302@sepehrs.com> <20110917203218.GC13993@michelle.cdnetworks.com> <CACqU3MXffDvH%2B5E3_excGswvsYx0eJ1WxTP16tswy9eK%2BvyH%2Bg@mail.gmail.com> <20110918210647.GA8930@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN <pyunyh@gmail.com> wrote: >> > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: >> >> Hi list, >> >> >> >> The data sheet for intel 82576 advertises IP TX/RX checksum offload >> >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that >> >> driver (and chip) do not support IP TX checksum offload or the support for >> >> TX is not yet included in the driver? > ... >> This is slightly off-topic, but still.. >> >> FWIW, I'm not really impressed by what chips claim to support vs. what >> has been implemented in the driver. As per the product brief, the > ... >> [0]: the commit message say "performance was not good", but it is not >> the driver's developer to decide whether or not a feature is good or >> not. The developer's job is to implement the chip capabilities, and >> let it to the user to enable or disable the capabilities. At best, the >> developer can decide whether or not to enable the feature by default. > > actually, this is a perfect example where the developer has done the > right thing: implemented the feature, verified that performance is bad, > hence presumably removed support for the feature from the code (which also > means that the normal code path will run faster because there are no > run-time decisions to be made). > > "optional" features are often costly even when disabled. > I forgot to mention that in this case, the code full of EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with the multiqueue's architecture. The only thing removed is a conditional and an assignation in the driver's attachment which was enabling the feature, ie. the cost you point out is still paid today, without any benefit. Now I might also openly question the test method used by the folks at Intel, just seeing how much issue I've had with the driver (I still have for some, even if not driver related), which have not been reproduced there. Finally, when someone say "performance are better that way", the first thing I'd be tempted to ask is: "What is your test ? How did you collects the numbers ? How did you reach the conclusion ?". None of this stuff is public. regards, - Arnaud
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MXSms9M-H9jj6zf5qWo05SLNCDBwDv%2B%2BmW5iTNjNLuKkA>