[brussels-dev] Fwd: Re: Brussels- nddcompat code review

[Garrett D'Amore]

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