Sowmini.Varadhan at Sun.COM wrote: > On (03/19/08 16:47), Garrett D'Amore wrote: > >>> But there are other outliers.. nge, for example has a bunch of >>> parameters for bcopy/dma thresholds. Yes, these should >>> be auto-tuned, but they are not, and until they are auto-tuned, >>> we need some way to control them. >>> >>> >> Yes, and we have that via dladm. I don't think we need access via NDD. >> >> Maybe. I still think there is significant value in supporting MII for >> ndd, at least until the various consumers of ndd have been converted. >> SunVTS comes to mind, and I'm sure there are customer scripts as well. >> >> But all those consumers are consumers of "well-known" properties (MII >> stuff), so if we did a "limited" amount of NDD support, I think it would >> be fine. >> > > >>> I think there is some value in having mac_register_private_prop >>> interfaces. >>> >>> >> I do too. I'm just not sure that NDD is the best case for them. I think >> dladm needs to grow some ability to inquire about tunables (ala the '?' >> arg to ndd), but that is a topic for future consideration. If you could >> defer the mac_register_private_prop() (and maybe then look at >> table-based registration, etc.) until later, it may simplify your life >> right now. >> > > I don't think table-based registration is that much overhead actually. > Instead of passing one (name, flags) pair at a time and having > mac_ndd malloc and chain this together, the driver could pass > an array mac_priv_prop_t structures and mac could just bcopy > it over. > > Since none of the GLDv3 interfaces are Committed yet, > we can get some implementation experience with this and > modify it later if needed. >
Sounds fine to me. I still would like you to consider nixing some of the outliers though (the synonyms) if possible. -- Garrett > --Sowmini > >
