intel checksum offload

[Luigi Rizzo]

On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote:
> Hi,
> 
> On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo <rizzo at 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 at 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.

the above suggests that you have a wonderful opportunity: with just
a little bit of time and effort you should be able to complete/re-enable
the missing code, run tests that you believe significant (given
your statement below) and prove or disprove the comment about
performance.

cheers
luigi

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