[brussels-dev] Re: [driver-discuss] Re: Brussels high-level design document

[sowmini.varadhan at sun.com]

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.

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

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

I like Raymond's proposal..

--Sowmini