Subject: Re: TSO on wm(4) (Intel Pro/1000): i82546 vs i8254EI vs others?
To: Jason Thorpe <thorpej@shagadelic.org>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: port-i386
Date: 05/23/2005 13:00:32
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.