[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
http://opensolaris.org/mailman/listinfo/brussels-dev
_______________________________________________
networking-discuss mailing list
[email protected]
