[rft] ath - tx/rx chainmask tidyup in preparation for AR9380 support
Hi, As part of the AR9380 support that's hopefully appearing soon, I finally found the motivation to tidy up how the chainmask handling is done. The summary: * introduce a new HAL method that changes the currently configured TX/RX chainmask; * leave the TX chainmask as 1 for non-HT and the hardware default for HT; * leave the RX chainmask as the hardware default for HT; * push the chainmask decision making into the driver - and have it done before each call to ath_hal_reset() TODO: * upon a channel reset, I need to absolutely make sure that anything that's in the hardware queue gets dequeued and requeued with whatever the new rate control information is. This includes channel width changes and chainmask changes. I'd appreciate it if people running ath(4) on -HEAD would try this out. It shouldn't break non-11n NICs but I should test those out too. http://people.freebsd.org/~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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 ___ 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 capabilities * track what the remote node rxmax/density is * have a couple of functions that return the density and rxmax based on the destination node and current VAP config * teach the 11n drivers to use that. 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 yes, what we should do is: * initialise rxmax/density with the VAP capabilities * track what the remote node rxmax/density is * have a couple of functions that return the density and rxmax based on the destination node and current VAP config * teach the 11n drivers to use that. Don't make it to complex, it's one-liner, not sure it's worth a function. The STA case is handled here because there is no later position to do so, AP already told us what it is capable of (ni_htparams) now it's the STA's job to do the same. The AP case is handled somewhere else, assoc req I guess, and that just uses the VAP params to verify the limits aren't above device caps. Using plain ni_htparams after that is just fine. If also done right in STA mode, ni_htparams will always contain a value which doesn't exceed either the AP's or the STA's or the device's limits (might have to change the value exactly there), so, using it directly is fine in drivers. I don't want to get into IBSS mode just yet, it's way to complex to get my head around that atm. Though, I think, it's a per-node and not a global parameter so the handling should match that from the AP? -- Bernhard ___ 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 kept the original mail it might be easier to figure out what you are refering to. :) If you ment the stuff I wrote about IBSS, well, as I said, IBSS is way to complex for me right to think about.. -- Bernhard ___ 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 be done for AP mode. STA mode should do the same too - it just happens there's only one node (the AP.) We have the same issue with 2040, shortgi, stbc, ldpc - ni_htparams includes what the peer node has, not necessarily what you've negotiated. So in the ath(4) driver I needed to look at both what _my_ capabilities are _and_ the remote capabilities before I decide whether to use 40mhz, shortgi, etc. It'd be shinier if there were some net80211 functions that did this for me. 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 capping those parameters to the learnt-from-AP parameters? 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 VAP ampdumax and ampdudensity no matter what the operating mode? Why are we capping those parameters to the learnt-from-AP parameters? Because the AP would otherwise deny the association request. That's at least how I read the commit (r173865). -- Bernhard ___ 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
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
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 capabilities when we associate, right? Correct. I didn't patch it right, but all of us agree on sta isn't sending correct param at association. With current code, sta sends back whatever it has received in probe resp packet. Why aren't we just advertising the VAP ampdumax and ampdudensity no matter what the operating mode? Why are we capping those parameters to the learnt-from-AP parameters? Because the AP would otherwise deny the association request. Should ap only allow node which caps match ap's to associate? (By the way, can anyone point me to the code does denial? I couldn't find it.) AK ___ 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
[RFT] net80211 TX serialisation, take #4
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. 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 point. I'd like to avoid making the VAP TX lock a reentrant lock (ew.) I'm open to ideas/suggestions. 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
Re: [RFT] net80211 TX serialisation, take #4
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 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 point. I'd like to avoid making the VAP TX lock a reentrant lock (ew.) Well, it turns out that this is almost-but-not-really-right. The problem is this: * A frame is going out on VAP A * so the VAP TX lock is held for VAP A * then the driver if_transmit() method is called, which will (for now) map to enqueue and call driver if_start() * now, if_start() will dequeue the top frame, which may be for VAP B this is fine so far, as the VAP lock is intended to serialise stuff through to the driver transmission phase. It's not designed to serialise _between_ VAPs. However, then we have a little hiccup. iwn and ath use the ni_txseqs[] space for TX sequence numbers when transmitting aggregate frames. I guess mwl does sequence number allocation in-firmware. So to be correct, i should grab the VAP lock when the driver transmit code wants to assign sequence numbers. However I can't do that: (a) It may already have it held from the net80211 call; (b) it may NOT already have it held (eg from a deferred call to the driver start method - eg, if the driver calls if_start after TX completion has occured, or upon driver reset to start TX again); (c) it may have a VAP lock held from a _different_ VAP, because of the conditions above. 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 lock is held when it decides to grab/increment sequence numbers from ni-ni_txseqs[]. This is all pretty terrible. Honestly, what I really need is a way to do this: * serialise frame TX handling in net80211 so the sequence of frames handed to the driver _matches exactly_ the sequence going through the VAP TX code, the VAP management TX code, etc.; * call the driver without the VAP or IC TX lock held - at this point, the frames should be in the driver queue _in the order_ they were processed via the VAP TX and management / raw TX path; * the driver can grab the VAP / IC TX lock if it needs to allocate sequence numbers itself; * the driver is then responsible for ensuring that frames are processed to software/hardware queuing in the same order they were received from net80211 (so CCMP IV sequence assignment is 'correct' too); * .. and do this without tearing my hair out. So the short term fix is: * convert my VAP TX Lock to an IC TX lock; * for the drivers that touch the ni_txseqs[] values (ath, iwn at least) - have them grab the IC TX lock before any deferred if_start/if_transmit call - that way the driver TX path holds the same locks no matter whether it came from the net80211 stack or a deferred start; * chase down and eliminate any and all of the rest of the subtle packets out of sequence crap that occurs when you're doing high throughput 802.11n with CCMP encryption; * .. think about how to properly separate out the queuing from the driver processing. I'm open to suggestions here. 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
Re: [RFT] net80211 TX serialisation, take #4
.. 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-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
