sowmini.varadhan at sun.com wrote:
> On (06/19/07 22:28), Raymond LI wrote:
>
>>>> 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 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.
>>>
>
> One of the features that makes ndd very popular is that it allows
> the setting of these debug/workaround knobs "on the fly", i.e., no reboot
> required (as in /etc/system), and the driver can actually re-adjust
> its state based on the setting requested (mdb cannot trigger state
> re-adjustment in the driver by itself).
>
> Providing a way to do this on-the-fly debug/workaround setting was
> one of the motivations for private properties. I agree that there is a
> danger of abuse here, and maybe we can think of ways to control
> the danger (by controlling documentation, perhaps?), but I see a benefit
> in having private props for the short term, at least.
>
>
In this particular case, changing the checksum capability actually
requires renegotiation with IP. I'm not sure whether IP is equipped to
deal with that or not. (I think the ability may have been added.)
In any case, this is *debug*, not normal usage, and should never be
needed if the hardware and drivers are working properly. (I.e. if they
aren't suffering from bugs.) An mdb or /etc/system tunable is fine
here... it may require the customer to unplumb/replumb the interface,
but, again, we do not expect this to be used unless our
software/hardware is somehow buggy. Its far better that we make sure
the checksum support is bug free than that we give customers some knob
to control it, IMO.
>>> 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.
>>>
>
> Actually, I myself felt that bcopy/dma threshold, as well as
> some of the ipg properties that have been suggested as public property
> candidates, also fell in the "Advanced Usage" bucket..
>
"Advanced usage" != debug usage. Those values are perfectly reasonable
things for the customer to tune, at least as long as we don't have a
facility in place to auto-tune them. (One could argue that the
bcopy/dma stuff should not be customer tunable, but right now we don't
have any facility to auto-tune them. The ipg properties are definitely
a customer tunable, and do represent unusual/advanced usage, but they
aren't something that we can auto-tune for the customer.)
>
>> 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.
>>
>
>
We need to be careful about how much we expose customers to, and what
guarantees we provide. If we plan on removing certain values in the
future, we should definitely set that expectation with our customers.
-- Garrett
> I like Raymond's proposal..
>
> --Sowmini
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://opensolaris.org/mailman/listinfo/brussels-dev
>
