In message <1E2AD2FD-7A50-49B6-90E5-E0722424BFCA@shagadelic.org>,
Jason Thorpe writes:

>On May 22, 2005, at 12:35 PM, Jonathan Stone wrote:
>
>> The 82544 works for me, insofaras ttcp works with TSO enabled;
>> but I don't see a performance gain. Is there a software workaround?
>> (The words "at one point" hint that way.)
>>
>> If not, then on balance I'd prefer that wm(4) not set the CSUM_TSOv4
>> capability on 82544 chips.  Objections?  Comments?
>
>It reduces CPU load "a little", and Linux still leaves it enabled on  
>those chips.  So why not?

Err? Isn't it obvious?  I guess not, or you wouldn't ask, so here goes:

For a send-only workload for ttcp, I expect TSO to roughly halve CPU
overhead.  The 82544ei shows a meagre gain, on the order of lowering
CPU use for a 123 Mbyte/sec send from 50% to 45%. (the gap may be
narrower, I didn't measure the non-TSO case carefully). Thus, to me,
with those expectaions, advertising TSO for an 82544 appears rather
like false advertising.

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.