> I ran into a question with the location of the door call to
> restore properties, and wanted to get some opinions.. not sure
> if Clearview can also encounter something similar.
>
> In the current Brussels design, we call mac_restore_prop early in
> xxx_attach function (e.g., bge_attach) and use this call to load up
> property definitions made via dladm.
>
>
> The idea is to have property values available early in attach: we do
> the property restoration early in attach because many properties
> (esp private ones, that are used in chip initialization, for example) are
> needed early in the attach.. the ddi model makes them available at attach,
> and many drivers are written based on that assumption.
>
> Wherever possible, we are reworking that assumption (e.g., with default_mtu)
> to make the code more flexible, but since we won't be able to fix every
> driver overnight, we want to have a property restoration model that
> provides a similar capability.
>
> The flexibility provided by Brussels for a feature like default_mtu is that
> the value of the property can be modified at any time, as long as the
> interface is in the unplumbed state. In the case of default_mtu,
> this constraint is placed because there are some stack allocations,
> ring assignments etc. that are based on the mtu size. The model
> provided is that if a user plumbs and interface and then defines mtu
> (via dladm), an error message will be posted that the change will be
> effective in the next unplumb/plumb. The requested mtu value will be
> stored in the persistent database (currently linkprop.conf) and
> restored at the next plumb.
>
>
> The above will work if, between an unplumb and plumb, a detach/attach
> also occurs. But this may not always be the case.
>
> For example, if I take a machine with bge0 as my primary internet
> connection, and try to modify values on the bge1 interface, say,
>
>
> # ifconfig bge1 plumb
>
> # dladm set-linkprop -p mac_default_mtu=9000 bge1
>
> <.. get message about needing replumb ..>
>
> # ifconfig bge1 unplumb
>
> the devi_detach->mac_unregister will not happen until the mt_config_thread is
> scheduled at some arbitrary time in the future. Thus, if I quickly do
> {unplumb; plumb}, bge1 will not go through attach code and the new mtu
> value will not be picked up.
>
> A couple of solutions to this are possible: we could handle this
> in the mac layer itself: unload the loaded mac properties in
> mac_unload_prop in mac_stop and, in mac_start, we can make a door call
> to cause the listening dladmd to do the equivalent of "dladm
> init_linkprop". We can avoid duplicate door calls (when the driver does
> attach + stop) by keeping track of the property load/unload state in
> the mac_handle. read properties both in bge_attach, as well as in
> mac_start
>
> Alternatively, in mac_stop, we could accelerate the devi_detach, but
> this solution (if it is even possible) seems like an intrusive
> change to the DDI framework, so it seems less attractive to me.
>
> Comments? Other possibilities?
>
I was actually discussing this (the initialization of the linkprop) with
Meem the other day, and I am thinking of to call the dladm_init_prop()
in the rcm framework (specifically, in network_rcm when it discovers a
new physical link.
I don't know whether it is already late to initialize some linkprops
when network_rcm discovers the new links though.
- Cathy
> --Sowmini
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org
>
