intel checksum offload
jfvogel at gmail.com
Mon Sep 19 04:55:05 UTC 2011
On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
> 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>
> >> > 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>
> >> >> > 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
> >> >> >> 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.
> >> >> has been implemented in the driver. As per the product brief, the
> >> > ...
> >> >> : 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,
> >> >> 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
> >> > hence presumably removed support for the feature from the code (which
> >> > 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, 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
> : 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
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
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.
More information about the freebsd-hackers