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
On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd wrote:
> The trouble with using a queue is that things will dequeue frames out
> of order, bceause multiple dequeue contexts (ie, each call to
> driver_start / driver_transmit) will execute in-parallel.
Actually, to prevent that, there is an extra qu
Here we go:
http://people.freebsd.org/~adrian/ath/20130225-net80211-txlock.diff
See what you think.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "fre
The trouble with using a queue is that things will dequeue frames out
of order, bceause multiple dequeue contexts (ie, each call to
driver_start / driver_transmit) will execute in-parallel.
Yay.
adrian
___
freebsd-wireless@freebsd.org mailing list
htt
On Sun, Feb 24, 2013 at 12:45 AM, Adrian Chadd wrote:
> On 23 February 2013 22:30, PseudoCylon wrote:
>>> So, this is all pretty terrible. The only sane solution for now is to
>>> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all
>>> VAPs. That way the driver can grab the IC TX l
On 23 February 2013 22:30, PseudoCylon wrote:
>> So, this is all pretty terrible. The only sane solution for now is to
>> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all
>> VAPs. That way the driver can grab the IC TX lock when it's doing
>> deferred sends and it'll be sure the
> --
>
> Message: 12
> Date: Fri, 22 Feb 2013 17:18:44 -0800
> From: Adrian Chadd
> To: freebsd-wireless@freebsd.org
> Subject: Re: [RFT] net80211 TX serialisation, take #4
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-
.. and as a reference, Linux mac80211 seems to just do TX through a
single-threaded workqueue. Ie, all of the mac80211 TX is done deferred
and serialised that way.
Grrr.. I'm very tempted to just do this and be done with it for now.
Adrian
___
freebsd
On 22 February 2013 15:25, Adrian Chadd wrote:
> Hi,
>
> Here's take four of the TX serialisation.
>
> http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff
>
> This patch increases the lock "reach" so it locks the encap path for
> both data and management frames, so the path betw
Hi,
Here's take four of the TX serialisation.
http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff
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.
T
10 matches
Mail list logo
