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