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