In message <1116900795.801960.1066.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:

>> I'd be much happier if the driver printed a message warning when
>> attaching an 82544, to the effect that TSO doesn't gain anything
>> signficant due to a hardware errata.  Or print a short warning,
>> and explain the issue in detail in the manpage. Or _something_.
>> 
>> Advertising TSO, and then having it manifestly not work as expected,
>> isn't going to make users happy.  Or at least, not this user.
> 
>- i don't think if_capabilities implies any perfomance gains.
>  it just mean if it works or not.


Yamaoto-san, that strikes me as sheer nonsense.  In Jason's reply to
my original message, Jason reports that *Intel* says that, on this
specific chip, TSO doesn't work as specified.  Intel says it doesn't
work.  Why, then, is wm(4) advertising the capability?  Is it just
"because Linux does?", or because Matt Thomas wasn't aware of
that particular errata?


>- How much you gain from offloading depends on network stack implementation.
>  do you want to re-evaluate each drivers/devices and flip capabilities,
>  whenever network code is changed?  i don't think it's realistic.

No, that doesn't match the facts in this case. Jason reports that
Intel issued an errata saying that *on this specific chip*, the 82544,
TSO (aka LSO) doesn't work to spec.  At all. It's busted.  My findings
agree with Jason's report.



>in any case, if you want to discourage users to use the functionality,
>manpage is a right place to change, IMO.

Remember: the current state of affairs is that an i82544 is attached
with CSUM_TSOv4 advertized. But when enabled, the TSO offload doesn't
work to spec.

I prefer to emit a one-line warning when 82544 devices are attached,
saying that TSOv4 is enabled but adoesn't work properly.  Once warned,
a careful admin may then check the manual or the source code.