Here's take four of the TX serialisation.
This patch increases the lock "reach" so it locks the encap path for
both data and management frames, so the path between sequence number
allocation and driver queuing is held.
There are some drivers that directly access ni_txseqs (ie, iwn and
ath) and I'll have to think about this a little more. Sometimes it'll
be called with the VAP TX lock held (ie, if it's called from driver
if_transmit / driver if_start / ic_raw_xmit) but sometimes the TX path
is called from the addba response callback, the TX completion methods,
a software frame taskqueue. None of these grab the VAP TX lock at any
I'd like to avoid making the VAP TX lock a reentrant lock (ew.)
I'm open to ideas/suggestions.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"