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.
Regards,
Miles Xu
_______________________________________________
networking-discuss mailing list
[email protected]
