On May 23, 2005, at 8:00 PM, Jonathan Stone wrote:

> 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?

Empirically, it "works".  That is to say it exercises the offload  
code path as intended and generates valid packets on the wire.

> 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.

And that could simply have been "didn't meet product marketing's  
performance requirements".  The 82547 is way more broken than the  
82544 :-)

> 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.

But from an end-user's perspective, it DOES work "properly".  It just  
doesn't provide much benefit on that particular chip (but even your  
measurements indicate that there is _some_ benefit).

-- thorpej