Hi, Right - but then I still need to hold long held locks here across the net80211 _and_ the driver.
Ie: * net80211 needs to hold a lock for the entire process of dequeuing a frame and running it to completion. It can't do this: * grab lock * dequeue frame * release lock --> here things race * grab net80211 lock * run with frame * release net80211 lock So you have to hold _some_ lock for the entire length of time you're processing that frame: * grab queue lock * dequeue frame * grab net80211 lock * process frame * release net80211 lock * release queue lock Same deal goes with the driver. That's the unfortunate side effect of having multiple stack and driver transmit paths all wanting to service the same queue. So either you have these long held locks but you can do fully inline, direct-dispatch transmit; or you use taskqueues and just serialise everything through the taskqueue. Adrian _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
