> In the case of DL-SET_PHYS_ADDR_REQ on the /dev/net node, won't the path > be something like > > proto_setphysaddr_req -> mac_unicst_set(mac of the softmac endpoint) -> > softmac driver -> DL_SET_PHYS_ADDR_REQ (ce DLPI driver)
Correct. > If the softmac driver changes the hardware address in its 'softmac' > structure before sending the DL_SET_PHYS_ADDR_REQ request down to the ce > driver, then the softmac won't see any address change when it receives > the DL_NOTE_PHYS_ADDR notification from the ce driver. Only in the /dev > case the DL_SET_PHYS_ADDR_REQ bypasses softmac. In this case the softmac > will find that the address has changed and it needs to do > mac_unicst_update based on the notification ? Yes, Cathy and I explored that too. However, there are two problems: (1) we don't know if the underlying driver will accept the DL_SET_PHYS_ADDR_REQ, so it's premature to update our address, and (2) even if we introduced another field to track the pending address change, the notification from the driver is asynchronous (and may never occur), so we can't be guaranteed that we can correlate it with the original DL_SET_PHYS_ADDR_REQ to the driver. For instance, suppose another DL_SET_PHYS_ADDR_REQ is immediately issued after the first one, but we have not yet received the notification for the first one from the driver; do we assume the notification will never come and update the "pending address" field with the new address? If we then receive the DL_NOTE_PHYS_ADDR for the first address, we'd erroneously call mac_unicst_update(). Going through all of this to avoid 3 lines of code in the framework seems hard to justify. > Looking at aggr, there seem to some complex cases, but it looks like the > aggr driver handles the cases and keeps track of when the address really > changes and calls mac_unicst_update only when the address has really > changed. I haven't studied aggr in this respect, but since the framework can easily determine whether the address has really changed, it seems preferable to move this logic into the framework and simplify aggr, no? > > Is this viable? If so, it seems like it would make sense to do this for > > other "update" routines where the requested state matches the current > > state known to the framework. > > > I guess it won't harm to have the extra check in mac_unicst_update, but > I am not sure. Nicolas/Eric may know the history here. OK. Nicolas? Eric? -- meem
