intel checksum offload

[Arnaud Lacombe]

Hi,

On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo <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> 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.
>
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.