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. --Sowmini
