James Carlson wrote:
Raymond LI - Sun Microsystems - Beijing China writes:
Garrett D'Amore wrote:
Its because it doesn't need to be tunable. The framework negotiates
this feature with the drivers... it always enables the feature if the
driver can support it. There is never any reason to disable it.
I had met questions from customer who complained his/her application
failed because all 0x0000 in TCP/IP's checksum field. If we provide
customer with better grained tuning over checksum capability, he/she
might be able to shoot or debug problems more efficiently. And we could
see most morden day drivers in Windows/Linux have tx/rx checksum tunable
respectively. I believe at least for debug/workaround reasons, we should
have this as an option to customer.
I agree with Garrett that we have just *way* too many tunables on our
drivers. These are the sorts of things that should "just work" and
should not require fiddling with knobs. I'd go further to say that
many -- perhaps all -- of the performance knobs are also in that boat,
and should be self-tuning.
I understand the occasional need to work around a bug in the field or
to help someone in services debug a customer issue. Those are, I
think, the sorts of things where we ought to settle for hacks based on
/etc/system or mdb, rather than baking a profusion of cryptic driver
'features' into a higher-level interface.
I'm sort of ambivalent about the idea of having a per-driver "private"
set of properties in Brussels, because I think it'll be abused in
_exactly_ this way -- to provide unnecessary tweaks like the bcopy/DMA
limit or putnext/putq switch.
Would it be good for us to retain them somehow in early phase of
Brussel, like by ways of keep it as "private" properties? For backward
compatibility reason, some customers might rely on those private
properties in their production env. Before we provide enough tuning in
framework, they will lose nothing.
As for Linux and Windows, I don't think they're really the exemplars
of good design here. We should probably try to do what's right for
OpenSolaris instead, and much of the impuse to tune strikes me as
--funroll-loops.
_______________________________________________
networking-discuss mailing list
[email protected]
