Right - but then I still need to hold long held locks here across the
net80211 _and_ the driver.


* 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.

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to