On Sat, 2009-08-15 at 09:55 -0400, Sebastien Roy wrote: > Hi Nicolas, > > On Fri, 2009-08-14 at 21:10 -0700, Nicolas Droux wrote: > > One goal is to prevent multiple clients to simultaneously update the > > MTU. The perimeter should be sufficient to do this. > > I agree. This should be no different than updating any other property, > really, which simply involves holding the perimeter.
I've filed 6872221 to address the correctness of mac_set_mtu() separately. > > I don't remember issues related to re-entry with aggr from the top of > > my head. If there is one I agree that this should not require a > > workaround like this in mac. BTW, it's a bit silly to require a driver > > to call mac_maxsdu_update() while updating its MTU. If the framework > > is calling the driver to update the MTU it should know that the MTU is > > changing. > > I totally agree, but the semantics should be well-defined either way. > For example, if indeed the mac module is modified to change mi_sdu_max > and send notifications itself, then the (upcoming) driver API > documentation should make it clear that the mac_maxsdu_update() would > only need to be called when the MTU changes in all cases except for the > "mtu" link property. And I've filed RFE 6872222 to address this particular issue. -Seb
