Peter Memishian wrote:
> I've seen a few others that are weird though-- collision recovery
> algorithm tuning (enable proprietary back off algorithms), wake-on-lan
> tweaks, inter-packet-gap tuning, tweaks to support extended cabling,
> signal enhancement tweaks, proprietary (Bay networks) PHY based flow
> control schemes. Any of those would be private tunables. Many of them
> shouldn't be adjusted by the vast majority of sites. I'm not sure its
> fair to "hide" them, though. (Which is what lack of an enumeration API
> does.)
They are not really hidden, they are just not discoverable directly
through dladm. That is, the driver that has the proprietary PHY-based
flow control scheme can document that in its manpage, along with what the
various settings mean. Again, I believe this is the right balance. I
have not yet seen a convincing case made for a driver-private tunable the
admin needs to muck with where they can't be bothered to read the driver
manpage to learn about it first.
(As an aside, our network driver manpages really need some work -- many of
them still describe common stuff that is automatically handled by GLDv3,
and suggest direct programmatic access via DLPI primitives on their /dev
node; all of this text needs to be updated and much of it needs to be
changed to reference a common manpage that describes interacting with
/dev/net nodes. This has been on my TODO list forever but I never seem to
get to it.)
Yes, mine too.
But this really underscores a problem... a strategy assuming that manual
pages will continuously kept up to date with the software, to the point
that the only way to learn about tunables is through the manual pages,
flies in the face of reality. The *reality* is that manual pages often
lag software integrations by several builds, and sometimes aren't even
updated at all. The current sad state of NIC driver manual pages is an
excellent example of why relying on manual pages to provide accurate
information is an idea that sounds good, but proves out not to work so well.
Again, I don't think the properties need to be enumerated by default,
but there needs to be *some* way to locate these.
There is a precedent for this approach as well (beyond just ndd's '?'.)
Look at what cfgadm -x does. Or the new mixerctl features. Both of these
subsystems reasonably assume that the core operating system can't
necessarily keep track of all the useful tunables, and that there needs
to be a way for the framework to pass such commands to the users. (In
cfgadm's case it even includes help messaging content.) I think these
aren't the only two cases either -- I didn't do an exhaustive search,
these are just the ideas off the top of my head.
I just think the idea that there is a relatively small set of well-known
properties that need adjusting, that the set won't change often, and
there will be consensus for what that set is, flies in the face of
decades of experience of with NIC drivers.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
