One goal is to prevent multiple clients to simultaneously update the MTU. The perimeter should be sufficient to do this. There are also drivers which cannot change their MTU while they are started, but on the other hand some drivers may support this, and therefore we could depend on the drivers to do test for this condition instead of doing this from mac.
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. But this is really not even address the real issue. There's still the risk of having mac_perim_enter_by_macname() fail when it's called from dls_devnet_close() if there's any operation holding the perimeter in progress. dls_devnet_close() should be able to handle the case where there are pending MAC clients accessing the MAC instance and wait until all references to the mac_impl_t are dropped, or we should ensure that dls_devnet_close() is called only after these references are dropped, or we should change dls_devnet_close() to handle the case when it cannot enter the perimeter. Nicolas. On Aug 14, 2009, at 7:49 PM, Sebastien Roy wrote: > > On Fri, 2009-08-14 at 21:46 -0400, Sowmini.Varadhan at Sun.COM wrote: >> On (08/14/09 18:23), Thirumalai Srinivasan wrote: >>>> >>> The perimeter does ensure that only 1 thread can do mac_set_mtu() >>> at a >>> time on the given mac. But I am not sure why mac_set_mtu() wants to >>> call mac_mark_exclusive(). Is it that not all drivers implement the >>> mac_maxsdu_update() and so we can't change the mtu except if we >>> are the >>> only mac client ? >>> >> >> I think Girish and Nicolas had some complex phone discussions >> about this, so maybe they can elaborate. As I recall, it had to >> do with some re-entry in the aggr driver? > > If aggr does an upcall while handling a downcall, or even holds any > lock > while making an upcall, then isn't that a bug in the aggr driver? One > would assume that sane locking semantics cannot be maintained if locks > are allowed to be held while making both up and down calls. This is > why, in the new iptun driver, notifications to the mac layer are > handled > asynchronously without holding locks or perimeters (stress testing > revealed that this was the only way to make things work reliably). > > In any case, yes, if Girish or Nicolas could elaborate, that would be > nice. At the moment, I've had to remove the calls to > mac_mark_exclusive() in order to do any sort of stress testing with > GLDv3 that include setting the mtu link property. > > -Seb > > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss -- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. nicolas.droux at sun.com - http://blogs.sun.com/droux
