On (06/25/07 12:23), Sebastien Roy wrote: > Okay. While I understand what you've written at the top of page 10, there > are still questions in my mind. How does the software know whether or not > a given property is currently in effect, or won't be in effect until > something else is done at a later time? How will the administrator know > what to do to cause the properties to take effect if it's not immediate? > Are the conditions to cause a given property to take effect the same for > every driver which supports that property?
The conditions to cause a given property to be deferrred are entirely dependant on the way the driver itself is implemented. For example, it's possible that the driver implementation is incapable of changing mtu after it is started because, for instance, the mtu setting determines tx/rx buffer/ring allocation. In such a situation, it is the driver's responsibility to emit a log message saying when the change will be effective (e.g., the next stop/start pair). The dladm/gldv3 framework itself would not interfere with the behavior. > I'm not sure I can answer that question, as it could easily be either. > Maybe I can talk with you in private to resolve the issues here, as it > doesn't make sense to talk about the details without having a handle on the > big picture for MTU. here's a summary of our discussion: when an attempt is made to change the driver's mtu via dladm, then the driver will also need to update its mac registration (i.e., the mip->mi_info.mi_sdu_max_sdu value), at which time, the "mac_update_reg" function will invoke i_mac_notify(mip, MAC_NOTE_SDU_SIZE); > SIOCG*MTU isn't at the right layer, it's an IP thing. dladm show-link > already displays the link MTU properly without a Brussels property, so why > not just do what its already doing? (it currently uses the dlpi_info() > libdlpi function, which seems like the correct thing to do) Ok. I'll post a new revision with all these updates shortly.. --Sowmini
