--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 23, 2005 at 08:32:29PM -0700, Jonathan Stone wrote:
>=20
> In message <20050524023918.GX5530@bcd.geek.com.au>,
> Daniel Carosone writes:
>=20
> >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.
>=20
> Hi Daniel,
>=20
> 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.

I think Jason's point is that it "works" but it doesn't work well. As=20
evidenced by the fact that groups still support it. It's not that it sends=
=20
broken packets (in which case everyone'd want it turned off; see isses on=
=20
the 82547 chip), it just doesn't do as well as one'd want/expect. It does=
=20
better than "off", just only a little.

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

So update the man page!

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

Why are you asking if Matt has seen the errata? Jason wrote the driver...

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

I don't think anyone will object to a driver message indicating that there=
=20
is an issue with TSO on these chips.

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

Are you really sure they are opposed to it? It sounded in your earlier=20
notes like you wanted to disable TSO on this chip entirely...

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

and they were reacting to that. They felt (and it turns out agreed with=20
you) that turning the capability off was too drastic a move. Or at least=20
that's my take on it; I'll let them answer for what they thought.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCk873Wz+3JHUci9cRAv1PAJ4q6Th8Q8Ly8iaNxeN5eqigdU6fhwCfZ5Vw
iiRTuTYr11oPsUXGWv5SbdA=
=9i2n
-----END PGP SIGNATURE-----

--sdtB3X0nJg68CQEu--