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
