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
On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd adr...@freebsd.org 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,
On Sun, Feb 24, 2013 at 12:45 AM, Adrian Chadd adr...@freebsd.org wrote:
On 23 February 2013 22:30, PseudoCylon moonlightak...@yahoo.ca 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
--
Message: 12
Date: Fri, 22 Feb 2013 17:18:44 -0800
From: Adrian Chadd adr...@freebsd.org
To: freebsd-wireless@freebsd.org
Subject: Re: [RFT] net80211 TX serialisation, take #4
Message-ID:
CAJ-Vmom8HNLNc-=CogiF1v2pJHcn73rB0w9EOHoBtTjAp=j
On 23 February 2013 22:30, PseudoCylon moonlightak...@yahoo.ca 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
On 22 February 2013 15:25, Adrian Chadd adr...@freebsd.org 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
.. 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
___
