In message <20050524023918.GX5530@bcd.geek.com.au>,
Daniel Carosone writes:

>Agreed. There might be other reasons than performance you want to
>toggle this (perhaps fault-finding: witness recent issues debugging
>checksum over loopback vs offloading).
>
>Perhaps the performance gain is better on slow cpu machines, or in MP
>configs where biglock contention is an issue, or...  etc.

Hi Daniel,

Have you seen Jason's message? Jason's report is that *intel* says TSO
just doesn't work to spec on this chip; *Intel* issued an errata
saying that TSO was no longer supported on the 82544 chip.


>There's still a question of whether to enable it by default for these
>chips.  If the vendor considers it a desupported feature, I'd suggest
>we don't enable it by default, even if the capability and documented
>caveats allow an admin to choose to try it for themselves.

Nope; "enabled by default" is not my point at all (and I wish I'd seen
this before replying to Yamamoto-san.)

The CSUM_TSOv4 flag is a capability.  tSetting the capability doesn't
enable use of the feature; it only indicates the driver will honour
requests to enanble TSO on the interface.

The issue here is that a fairly expert admin (me) enabled the TSO
capability on an 82544; but it didn't work, for a reasonable
expectation of "work".  Jason then explained that Intel issued an
errata de-supporting TSO on the 82544.

I checked both the kernel source and (3.0 branch) manpages before
posting. I didn't see any indication that there were known problems
with TSO on 82544 chips. (Matt: I'm mildy curious, were you aware of
that errata or not?)

Anyway....  The minimum I'm asking for is that the driver print a
shortattach-time (or enable-time) warning for i82544s chips: enough to
alert an admin who *does* enable TSO on an i82544 to read an (updated)
wm(4) manual page which explains this issue.

Daniel, Yamamoto-san: can one or other of you please explain to my why
any that is a controversial thing to want? Because, sincerely, I'm not
seeing _any_ reason why you, or Yamamoto-san, are opposed to it.
I mean, do you expect Jason to explain the problem to everyone who
does try to enable TSO on an 82544?

In contrast, disabling the capability altogether on this chip version
is far more heavy-handed: you'd have to build a custom kernel to
re-enable the capability.  That strikes me as a bit too heavy-handed...