intel checksum offload

[Hooman Fazaeli]

It is interesting that how a thread goes off topic!

Anyway, I will appreciate if folks, especially Jack, provide
a firm comment on the original question: Does intel chips (specifically 82576)
support IP TX checksum offload? If so, why the driver does not support it?

On 9/19/2011 8:59 AM, Jack Vogel wrote:
>
>
> On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe <lacombar at gmail.com <mailto:lacombar at gmail.com>> wrote:
>
>     Hi,
>
>     On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo <rizzo at iet.unipi.it <mailto:rizzo at iet.unipi.it>> wrote:
>     > 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 <mailto: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 <mailto: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.
>     >
>     Which I did about a week ago, to finally discover that the NIC only
>     had only 3 MSI-X vectors configured in its EEPROM[0], and thus the
>     MSI-X PCI capability field ends up also with being assigned with those
>     3 vectors. However, the  82574 datasheet clearly say that up-to 5
>     vector can be configured, but I obviously did not find the magic trick
>     to make it so. Maybe I'll find some time and try to reprogram the
>     EEPROM. Beside that, it was clear that the old multiqueue did not
>     support only 3 vector being available and thus fell back on MSI. It is
>     not clear in jfv@'s comment whether he really tested multiqueue, or
>     did he test the fall-back MSI mode.
>
>     As the PCI spec is not public, I've not been able to find out from the
>     few public datasheet how the PCI MSI-X capability field is first
>     programmed. I'd assume that the BIOS is using the data in the NVM to
>     program it at power up.
>
>      - Arnaud
>
>     [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2,
>     thus 3 vectors.
>
>
> I give answers to those who treat me with respect, I view them as
> collaborators, we improve the drivers for everyone's benefit, rather
> than jumping in to throw a critical remark here, a negative innuendo
> there...
>
> If you notice, the Linux driver did not enable multiqueue on the hardware
> either, so do you think a whole department of software engineers backed
> by the hardware engineers who designed the damn thing might have had
> a reason?
>
> IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and
> tried it for a while just because I could, implementing the code was not
> difficult. Over time however that code proved to be a source of instability
> and thus was disabled.
>
> I have heard a rumor that the Linux crew may actually be trying a second
> time to make it work, and that might give me cause to look at it again too,
> but its not clear if I'll have time with other priorities.
>
> Jack
>