Min Miles Xu wrote:
Peter Memishian wrote:
> All-in-all I think it's an excellent idea to remove as many
tunables as > possible, but when new h/w comes along it's generally
necessary to add > them because existing APIs/features within the
stack don't quire fit the > model. Those can be modified and the
tunables eventually removed, but > this is an iterative process and
thus, I believe, Solaris should have > good support for dynamic
driver tunables rather than trying to deny > their existence.
I still believe the right balance has been struck. As you imply above,
configuration knobs that have staying power will be regularly folded
into
the core stack, so the per-driver set should remain small and relatively
volatile. Again, common configuration infrastructure s critical to the
long-term ability to administer networking in Solaris -- we must not get
back into the mindset of requiring an administrator to follow different
procedures to get up and running with each and every driver. Further to
that, I explicitly do not want to build in a discovery -- we did that
with
ndd and it resulted in poorly-informed fiddling that ultimately led to
support calls. The admin should have a problem they're trying to solve
when reaching for a driver-specific knob, not just groping and hoping.
Regardless of the private property enumeration issue, frankly
speaking, most
drivers' private properties mean little to the admins in contrast to
the developers.
Not all the admins have the knowledge to operate the private
properties properly
even if they're documented. And I believe most NIC drivers can deliver
a generally
optimized performances without manually tuning the private properties.
But for
specific applications, it may require the admins to tune the drivers
to gain better
performances. My idea is to have the toggles such as "optimized for
small packets",
"optimized for forwarding". And it may be a vertically optimized stuff
in stack,
not just tuning the drivers. I think it's more directive and valuable
for admins
and service engineers.
To be honest, its the performance analysis folks and the benchmarking
folks that IMO cause most of these tunables to be created. Many --
daresay I most -- sites shouldn't be adjusting any of these
"performance" tunables off their defaults. But in the quest for ever
higher benchmarks, perf. folks look for tunables for all kinds of weird
things which mere mortals shouldn't touch. And they frequently insist on
having direct access to each and every one of those knobs. And making
matters worse, its usually the case that those knobs "have" to be
exposed to customers or the benchmark results for which they are created
is often invalidated.
I'd love it if drivers could suppress many of these tunables that are
just perf. tweaks. Heck, in many cases those tweaks actually *hurt* the
general performance by adding extra complexity to drivers that otherwise
wouldn't need it. (Extra branches on hot code paths for example.)
In the search for the optimum results for a specific benchmark, the
driver pays a penalty for general testing. I abhor this kind of tuning,
and I wish the industry would just stop doing it.
Unfortunately, the worst hurt by this are usually the "premier" device
drivers -- the ones that get the most attention for performance
tweaking. I submit for your consideration -- cassini. But I think nxge
suffers in much the same way.
Now, all that said, there remain legitimate needs for enumerated
tunables. If I were to build a brussels version of the elxl driver, for
example, I'd like a tunable that let me select between MII, 10 Base-T,
10 Base-2, and AUI. This particular pattern I've seen before though, and
it may be common enough that it should be a standard property.
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.)
-- Garrett
Regards,
Miles Xu
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
