Garrett D'Amore wrote: >More concisely, mac_stop may be sufficient to provide a guarantee to the >framework that the driver will not upcall (although I'm not sure this is >true today), but it is *not* sufficient to provide a guarantee to the >driver that the framework will not later call mac_start() before >detach(9e) is called. > >Note also that if we want to make mac_stop() provide the guarantee to >the framework that no upcalls will happen, then we may have to go >through a bunch of the drivers and make sure that any asynch timeouts >are carefully protected... I think most (all?) of them disable >interrupts, but I'm not sure about cyclics, etc. > > Essentially Iam asking for the driver to reference count the number of pending upcalls and wait in mac_stop till they drop to zero, or some equivalent mechanism.
>On another question, why does the framework need this guarantee? > > After mac_resources(), the driver and the framework have pointers to each other's data. mac_rx and m_tx are called with opaque cookies to the other layer's data structures. We need a way to do the teardown and be sure the driver and the framework don't have stale pointers when the framework decides it is time to tear down - say when all mac clients are gone. In fact we may need a finer grain of control here with Crossbow on a per ring basis. A particular Rx ring could be assigned to a flow or vnic. When the flow or vnic is deleted we may need to quiesce the ring before reprogramming the ring for another flow or vnic (and rely on the hardware classification). >But see, this is where the driver wants to be able to have a simple call >to the nemo framework to say.... please check that its safe for me to go >away, and if you tell me so, then please *guarantee* that it will remain >so. > >Synchronization with *detach* requires that the driver be able to >quiesce the mac/framework, not the other way around. > > Sure. One way is for the driver to single thread itself before calling mac_register, but if that is a pain because mac_register can fail, and the driver has to undo its actions, your proposal of separating the unregister from the free is fine and solves that. Thirumalai _______________________________________________ networking-discuss mailing list [email protected]
