Subject: Re: TSO on wm(4) (Intel Pro/1000): i82546 vs i8254EI vs others?
To: YAMAMOTO Takashi <>
From: Daniel Carosone <>
List: tech-net
Date: 05/24/2005 12:39:18
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2005 at 11:13:15AM +0900, YAMAMOTO Takashi wrote:
> > Advertising TSO, and then having it manifestly not work as expected,
> > isn't going to make users happy.  Or at least, not this user.
> =20
> - i don't think if_capabilities implies any perfomance gains.
>   it just mean if it works or not.

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.

> - how much you gain from offloading depends on network stack implementati=
>   do you want to re-evaluate each drivers/devices and flip capabilities,
>   whenever network code is changed?  i don't think it's realistic.
> in any case, if you want to discourage users to use the functionality,
> manpage is a right place to change, IMO.

Agreed. Any subtleties and caveats and administrator considerations
can be much better addressed with words than with a single bit :)

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.


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.1 (NetBSD)