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. 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. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
