Garrett D'Amore wrote:
[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 agree that this is used mostly as "debug" options. We are trying to
keep the driver/hw bug free of checksum errors. But in real life
experience, the ideal scene seems not always exist. We have customers
meeting checksum bug's either from driver's software or a hardware
issue. Customer will have one more option to address the problem if we
provide this as an option.
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.
This is somewhat similar to what we discussed about "interrupt
coalecing", I think. Because we don't have a perfect auto-tuning way so
far, we need to keep that somewhere.
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.
Yes, I think so.
-- 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]
_______________________________________________
networking-discuss mailing list
[email protected]
