/~adrian/ath/20130222-ath-chainmask-ctrl-1.diff
Thanks,
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
The patch effectively reverts a previous change, which was to cap rxmax and
density by what the AP is capable of. I think the better approach would be to
initialize rxmax and density with the VAP capabilities before the condition
and use MIN() in STA mode to limit to AP caps.
--
Bernhard
Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
If an AP is transmitting to a STA that has a lower rxmax or higher
density, it should obey that.
The same rules apply for mesh, ibss, tdma operational modes.
So yes, what we should do is:
* initialise rxmax/density with the VAP
On Friday, February 22, 2013 07:04:39 PM Adrian Chadd wrote:
Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
If an AP is transmitting to a STA that has a lower rxmax or higher
density, it should obey that.
The same rules apply for mesh, ibss, tdma operational modes.
So
On Friday, February 22, 2013 07:34:30 PM Adrian Chadd wrote:
Hi,
Why isn't it a per-node thing for the AP case?
Ie, what should the AP do if the ampdu density it supports is 0 but
the STA AMPDU density on the RX side is 8?
What made you think it isn't? ni_htparams is per-node(ni)?
If you
Ah, damn. Sorry. I was thinking about the node versus vap
configuration and got confused.
IBSS is the same as the APmode of operation - you advertise what
you're capable of and sending stations just calculate the
MIN(ampdusize) and MAX(ampdudensity) when sending to you. Exactly the
same needs to
Hm, it's possible in my sleep deprived state that I'm on the right but
wrong track here.
The OP problem is that we're not advertising the right capabilities
when we associate, right?
Why aren't we just advertising the VAP ampdumax and ampdudensity no
matter what the operating mode? Why are we
On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote:
Hm, it's possible in my sleep deprived state that I'm on the right but
wrong track here.
The OP problem is that we're not advertising the right capabilities
when we associate, right?
Correct.
Why aren't we just advertising the
On Fri, Feb 22, 2013 at 12:05 PM, Bernhard Schmidt
bschm...@techwires.net wrote:
On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote:
Hm, it's possible in my sleep deprived state that I'm on the right but
wrong track here.
The OP problem is that we're not advertising the right
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.
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
___
12 matches
Mail list logo
