aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/ath/ath_rate
Commit message (Collapse)AuthorAgeFilesLines
* net80211 / LinuxKPI: 802.11: revert / redo enum ieee80211_sta_rx_bwBjoern A. Zeeb2025-08-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | The initial thought of migrating the LinuxKPI 802.11 enum into net80211 for shared use did not work out well. Currently in the need for yet another adjustment, I decided to undo/de-couple net80211 and LinuxKPI 802.11 again. The enum name now gets used in LinuxKPI based wifi drivers and it turns out it is spelt differntly than what I used initially. This creates a conflict. net80211 still in the need to be able to express BW_320 in an uint8_t will likely be fine with the current solution as well. Rename the enum and prefixes in net80211 to "net80211" instead of "ieee80211". Apart from the names/prefix we leave the values the same. In LinuxKPI add the enum with the expected name and use it there throughout to make modern versions of LinuxKPI based wifi drivers compile. Sponsored by: The FreeBSD Foundation Fixes: ca389486a9599, 2c8b0d6205f6f MFC after: 3 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D52064
* ath_rate_sample: fix setting HT ratesAdrian Chadd2025-03-011-1/+2
| | | | | | | | | | | | ieee80211_node_set_txrate_ht_mcsrate() takes an MCS rate from 0..76, the high bit (IEEE80211_RATE_MCS) must not be set. This is definitely my fault - I likely didn't get to testing this diff when I changed it from ieee80211_node_set_txrate_dot11rate() just before landing. Differential Revision: https://reviews.freebsd.org/D49197 Reviewed by: bz
* sys: convert ni->ni_txrate references use to the new net80211 APIAdrian Chadd2025-02-263-10/+20
| | | | | | | | | | | This just mechanically converts things. * For linuxkpi, it was just used for display. * For uath, it was just used for display, as firmware doesn't report it up. Differential Revision: https://reviews.freebsd.org/D48602 Reviewed by: bz, thj
* ath_rate_sample: correct the "best rate" calculationAdrian Chadd2024-12-181-1/+2
| | | | | | | | | | | | | | | | | This should be a *9 rather than a *10 so higher stream MCS rates (eg comparing MCS0 and MCS8) that have slightly longer average transmit times (but better burst transmit times) get considered. This mirrors what the later code does when considering if a rate change is needed. Locally tested: * AR9280, AP mode * AR9380, AP mode Differential Revision: https://reviews.freebsd.org/D47988 Reviewed by: imp
* net80211 / LinuxKPI 802.11: use enum ieee80211_sta_rx_bw for ni_chwBjoern A. Zeeb2024-12-081-4/+4
| | | | | | | | | | | | | | | | | | | | | | | net80211 node ni_chw currently encodes the channel width as Mhz number. LinuxKPI 802.11 uses enum ieee80211_sta_rx_bw for the same. Rather than keeping the "20" and "40" throughout the code (eventually expanded to 80/160/320) switch them over to use the enum throughout and add a print mask for debug output. While designed as bitmask it is not supposed to be used as such; the bitmask is only used to be able to use %b with a print mask. Once we get to 320Mhz channel widths we would otherwise also need to extend the uint8_t in struct ieee80211_node; making enum ieee80211_sta_rx_bw __packed allows us for three more channel widths without breaking the KBI (if we were not to use %b with a print_mask but use a lookup function for the string we could extend it for a long time). Sponsored by: The FreeBSD Foundation MFC after: 14 days Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D47891
* ath: Handle errors from copyout() in ath_rate_fetch_node_stats()Mark Johnston2023-12-261-7/+17
| | | | | MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D43096
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-164-8/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-163-6/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-122-2/+2
| | | | | | | | | The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
* ath: clean up empty lines in .c and .h filesMateusz Guzik2020-09-014-15/+9
| | | | Notes: svn path=/head/; revision=365116
* [ath] Update ath_rate_sample to use the same base type as ticks.Adrian Chadd2020-05-271-1/+1
| | | | | | | | | | | | | Until net80211 grows a specific ticks type that matches the system, manually use the same type as the kernel/net80211 'ticks' type (signed int.) Tested: * AR9380, STA mode Notes: svn path=/head/; revision=361566
* [ath_rate_sample] Obey the maximum frame length even when using static rates.Adrian Chadd2020-05-211-0/+16
| | | | | | | | | | | | | I wasn't enforcing the maximum packet length when using static rates so although the driver was enforcing it itself OK, the statistics were sometimes going into the wrong bin. Tested: * AR9380, STA mode Notes: svn path=/head/; revision=361319
* [ath_rate_sample] Fix correct status when completing frames with short failures.Adrian Chadd2020-05-161-6/+26
| | | | | | | | | | | | | | | My preivous logic was a bit wrong. This caused transmissions that failed due to a mix of short and long retries to count intermediate rates as OK if the LONG retry count indicated some retries had made it to this intermediate rate, but the SHORT retry count was the one that caused the whole transmit to fail. Now status is passed in again - and this is the status for the whole transmission - and then update_stats() does some quick math to see if the current transmission series hit its long retry count or not before updating things as a success or failure. Notes: svn path=/head/; revision=361118
* [ath_rate_sample] Limit the tx schedules for A-MPDU ; don't take short retriesAdrian Chadd2020-05-163-15/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into account and remove the requirement that the MCS rate is "higher" if we're considering a new rate. Ok, another fun one. * In order for reliable non-software retried higher MCS rates, the TX schedules (inconsistently!) use hard-coded lower rates at the end of the schedule. Now, hard-coded is a problem because (a) it means that aggregate formation is limited by the SLOWEST rate, so I never formed large AMDU frames for 3 stream rates, and (b) if the AP disables lower rates as base rates, it complains about "unknown rix" every frame you transmit at that rate. So, for now just disable the third and fourth schedule entry for AMPDUs. Now I'm forming 32k and 64k aggregates for the higher density MCS rates much more reliably. It would be much nicer if the rate schedule stuff wasn't fixed but instead I'd just populate ath_rc_series[] when I fetch the rates. This is all a holdover of ye olde pre-11n stuff and I really just need to nuke it. But for now, ye hack. * The check for "is this MCS rate better" based on MCS itself is just garbage. It meant things like going MCS0->7 would be fine, and say 0->8->16 is fine, (as they're equivalent encoding but 1,2,3 spatial streams), BUT it meant going something like MCS7->11 would fail even though it's likely that MCS11 would just be better, both for EWMA/BER and throughput. So for now just use the average tx time. The "right" way for this comparison would be to compare PHY bitrates rather than MCS / rate indexes, but I'm not yet there. The bit rates ARE available in the PHY index, but honestly I have a lot of other cleaning up to here before I think about that. * Don't include the RTS/CTS retry count (and thus time) into the average tx time caluation. It just makes temporarily failures make the rate look bad by QUITE A LOT, as RTS/CTS exchanges are (a) long, and (b) mostly irrelevant to the actual rate being tried. If we keep hitting RTS/CTS failures then there's something ELSE wrong on the channel, not our selected rate. Notes: svn path=/head/; revision=361106
* [ath_rate_sample] Fix logic for determining whether to bump up an MCS rate.Adrian Chadd2020-05-161-9/+11
| | | | | | | | | | | | | | | | | | | | | | | * Fix formatting, cause reasons; * Put back the "and the chosen rate is within 90% of the current rate" logic; * Ensure the best rate and the current rate aren't the same; this ... * ... fixes the packets_since_switch[] tracking to actually conut how many frames since the rate switched, so now I know how stable stuff is; and * Ensure that MCS can go up to a higher MCS at this or any other spatial stream. My previous quick hack attempt was doing > rather than >= so you had to go to both a higher root MCS rate (0..7) and spatial stream. Eg, you couldn't go from MCS0 (1ss) to MCS8 (2ss) this way. The best rate and switching rate logic still have a bunch more work to do because they're still quite touchy when it comes to average tx time but at least now it's choosing higher rates correctly when it wants to try a higher rate. Tested: * AR9380, STA mode Notes: svn path=/head/; revision=361098
* [ath] [ath_rate_sample] le oops, trim out an #if 1 that I didn't fully delete.Adrian Chadd2020-05-151-1/+0
| | | | | | | | Cool, so now I know it's about 3 weeks between starting on freebsd coding and breaking the build again. Queue dunce cap. Notes: svn path=/head/; revision=361087
* [ath] [ath_rate] Extend ath_rate_sample to better handle 11n rates and ↵Adrian Chadd2020-05-154-134/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | aggregates. My initial rate control code was .. suboptimal. I wanted to at least get MCS rates sent, but it didn't do anywhere near enough to handle low signal level links or remotely keep accurate statistics. So, 8 years later, here's what I should've done back then. * Firstly, I wasn't at all tracking packet sizes other than the two buckets (250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and 65536. I may go add 2048 at some point if I find it's useful. This is important for a few reasons. First, when forming A-MPDU or AMSDU aggregates the frame sizes are larger, and thus the TX time calculation is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels isn't some fixed thing, both due to channel conditions and radios themselves. Notably, there was some observations done a few years ago on 11n chipsets which noticed longer aggregates showed an increase in failed A-MPDU sub-frame reception as you got further along in the transmit time. It could be due to a variety of things - transmitter linearity, channel conditions changing, frequency/phase drift, etc - but the observation was to potentially form shorter aggregates to improve BER. * .. and then modify the ath TX path to report the length of the aggregate sent, so as the statistics kept would line up with the correct bucket. * Then on the rate control look-up side - i was also only using the first frame length for an A-MPDU rate control lookup which isn't good enough here. So, add a new method that walks the TID software queue for that node to find out what the likely length of data available is. It isn't ALL of the data in the queue because we'll only ever send enough data to fit inside the block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr() would do. * .. and cache that in the first ath_buf in the aggregate so it and the eventual AMPDU length can be returned to the rate control code. * THEN, modify the rate control code to look at them both when deciding which bucket to attribute the sent frame on. I'm erring on the side of caution and using the size bucket that the lookup is based on. Ok, so now the rate lookups and statistics are "more correct". However, MCS rates are not the same as 11abg rates in that they're not a monotonically incrementing set of faster rates and you can't assume that just because a given MCS rate fails, the next higher one wouldn't work better or be a lower average tx time. So, I had to do a bunch of surgery to the best rate and sample rate math. This is the bit that's a WIP. * First, simplify the statistics updates (update_stats()) to do a single pass on all rates. * Next, make sure that each rate average tx time is updated based on /its/ failure/success. Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS 12 would have their average tx time updated for /their/ part of the transmission, not the whole transmission. * Next, EWMA wasn't being fully calculated based on the /failures/ in each of the rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure that the statistics noted that /all/ subframes failed at those rates, rather than the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average TX time are updated correctly. * When picking a sample rate and initial rate, probe rates aroud the current MCS but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at MCS8 then don't probe MCS7 as part of it, it's not likely to succeed. * Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and .. then each comparison would accept the higher rate. Just skip those; sampling will fill in the details. So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of instability around higher MCS rates because there are bursts of loss/retransmissions that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks. Ok, so why this still something I'm poking at? rather than porting minstrel_ht? ath_rate_sample tries to minimise airtime, not maximise throughput. I have extended it with an EWMA based on sub-frame success/failures - high MCS rates that have partially successful receptions still show super short average frame times, but a /lot/ of retransmits have to happen for that to work. So for MCS rates I also track this EWMA and ensure that the rates I'm choosing don't have super crappy packet failures. I don't mind not getting lower peak throughput versus minstrel_ht; instead I want to see if I can make "minimise airtime" work well. Tested: * AR9380, STA mode * AR9344, STA mode * AR9580, STA/AP mode Notes: svn path=/head/; revision=361085
* [ath] [ath_rate] Add some extra data into the rate control lookup.Adrian Chadd2020-05-133-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now (well, since I did this in 2011/2012) the rate control code makes some super bad choices for 11n aggregates/rates, and it tracks statistics even more questionably. It's been long enough and I'm now trying to use it again daily, so let's start by: * telling the rate control code if it's an aggregate or not; * being clearer about the TID - yes it can be extracted from the ath_buf but this way it can be overridden by the caller without changing the TID itself. (This is for doing experiments with voice/video QoS at some point..) * Return an optional field to limit how long the aggregate is in microseconds. Right now the rate control code supplies a rate table and the ath aggr form code will look at the rate table and limit the aggregate size to 4ms at the slowest rate. Yeah, this is pretty terrible. * Add some more TODO comments around handling txpower, rate and handling filtered frames status so if I continue to have spoons for this I can go poke at it. Notes: svn path=/head/; revision=360998
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many)Pawel Biernacki2020-02-211-6/+6
| | | | | | | | | | | | | | | | | | r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all low hanging fruits as MPSAFE. Reviewed by: markj Approved by: kib (mentor, blanket) Differential Revision: https://reviews.freebsd.org/D23626 Notes: svn path=/head/; revision=358224
* [ath_rate_sample] Have the final attempted rate in 11n modes to be the ↵Adrian Chadd2019-05-051-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | lowest one. Right now ath_rate_sample has a fixed rate schedule, rather than the minstrel_ht style "best, good, most reliable" triplet. So, if higher rates are tried then it'll not fail back to a lower MCS rate in that transmission schedule. This means that in low SNR situations it'll not easily drop to MCS0 unless enough transmissions occur to allow rate control to eventually decide to drop; and if it's TCP traffic it'll get slowed down because of packet loss. It's worse for 2-stream and 3-stream rates; it doesn't ever fall back to lower stream rates, and these higher stream rates required higher SNR to work. So instead let's (for now?) have each of the 11n transmit rates use MCS0 as the last attempt. ath_rate_sample will quickly see that rate succeeds more and will move to it much quicker. Testing: * AR9344 (Wasp) - 2G STA mode Notes: svn path=/head/; revision=347141
* [ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking ↵Adrian Chadd2019-05-053-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode Notes: svn path=/head/; revision=347140
* sys/dev: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-277-0/+14
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326255
* [ath] [ath_hal] (etc, etc) - begin the task of re-modularising the HAL.Adrian Chadd2017-05-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the deep past, when this code compiled as a binary module, ath_hal built as a module. This allowed custom, smaller HAL modules to be built. This was especially beneficial for small embedded platforms where you didn't require /everything/ just to run. However, sometime around the HAL opening fanfare, the HAL landed here as one big driver+HAL thing, and a lot of the (dirty) infrastructure (ie, #ifdef AH_SUPPORT_XXX) to build specific subsets of the HAL went away. This was retained in sys/conf/files as "ath_hal_XXX" but it wasn't really floated up to the modules themselves. I'm now in a position where for the reaaaaaly embedded boards (both the really old and the last couple generation of QCA MIPS boards) having a cut down HAL module and driver loaded at runtime is /actually/ beneficial. This reduces the kernel size down by quite a bit. The MIPS modules look like this: adrian@gertrude:~/work/freebsd/head-embedded/src % ls -l ../root/mips_ap/boot/kernel.CARAMBOLA2/ath*ko -r-xr-xr-x 1 adrian adrian 5076 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_dfs.ko -r-xr-xr-x 1 adrian adrian 100588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal.ko -r-xr-xr-x 1 adrian adrian 627324 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_hal_ar9300.ko -r-xr-xr-x 1 adrian adrian 314588 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_main.ko -r-xr-xr-x 1 adrian adrian 23472 May 23 23:45 ../root/mips_ap/boot/kernel.CARAMBOLA2/ath_rate.ko And the x86 versions, like this: root@gertrude:/home/adrian # ls -l /boot/kernel/ath*ko -r-xr-xr-x 1 root wheel 36632 May 24 18:32 /boot/kernel/ath_dfs.ko -r-xr-xr-x 1 root wheel 134440 May 24 18:32 /boot/kernel/ath_hal.ko -r-xr-xr-x 1 root wheel 82320 May 24 18:32 /boot/kernel/ath_hal_ar5210.ko -r-xr-xr-x 1 root wheel 104976 May 24 18:32 /boot/kernel/ath_hal_ar5211.ko -r-xr-xr-x 1 root wheel 236144 May 24 18:32 /boot/kernel/ath_hal_ar5212.ko -r-xr-xr-x 1 root wheel 336104 May 24 18:32 /boot/kernel/ath_hal_ar5416.ko -r-xr-xr-x 1 root wheel 598336 May 24 18:32 /boot/kernel/ath_hal_ar9300.ko -r-xr-xr-x 1 root wheel 406144 May 24 18:32 /boot/kernel/ath_main.ko -r-xr-xr-x 1 root wheel 55352 May 24 18:32 /boot/kernel/ath_rate.ko .. so you can see, not building the whole HAL can save quite a bit. For example, if you don't need AR9300 support, you can actually avoid wasting half a megabyte of RAM. On embedded routers this is quite a big deal. The AR9300 HAL can be later further shrunk because, hilariously, it indeed supports AH_SUPPORT_<xxx> for optionally adding chipset support. (I'll chase that down later as it's quite a big savings if you're only building for a single embedded target.) So: * Create a very hackish way to load/unload HAL modules * Create module metadata for each HAL subtype - ah_osdep_arXXXX.c * Create module metadata for ath_rate and ath_dfs (bluetooth is currently just built as part of it) * .. yes, this means we could actually build multiple rate control modules and pick one at load time, but I'd rather just glue this into net80211's rate control code. Oh well, baby steps. * Main driver is now "ath_main" * Create an "if_ath" module that does what the ye olde one did - load PCI glue, main driver, HAL and all child modules. In this way, if you have "if_ath_load=YES" in /boot/modules.conf it will load everything the old way and stuff should still work. * For module autoloading purposes, I actually /did/ fix up the name of the modules in if_ath_pci and if_ath_ahb. If you want to selectively load things (eg on ye cheape ARM/MIPS platforms where RAM is at a premium) you should: * load ath_hal * load the chip modules in question * load ath_rate, ath_dfs * load ath_main * load if_ath_pci and/or if_ath_ahb depending upon your particular bus bind type - this is where probe/attach is done. TODO: * AR5312 module and associated pieces - yes, we have the SoC side support now so the wifi support would be good to "round things out"; * Just nuke AH_SUPPORT_AR5416 for now and always bloat the packet structures; this'll simplify other things. * Should add a simple refcnt thing to the HAL RF/chip modules so you can't unload them whilst you're using them. * Manpage updates, UPDATING if appropriate, etc. Notes: svn path=/head/; revision=318856
* [ath] [ath_hal] break out the duration calculation to optionally include SIFS.Adrian Chadd2016-07-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pre-11n calculations include SIFS, but the 11n ones don't. The reason is that (mostly) the 11n hardware is doing the SIFS calculation for us but the pre-11n hardware isn't. This means that we're over-shooting the times in the duration field for non-11n frames on 11n hardware, which is OK, if not a little inefficient. Now, this is all fine for what the hardware needs for doing duration math for ACK, RTS/CTS, frame length, etc, but it isn't useful for doing PHY duration calculations. Ie, given a frame to TX and its timestamp, what would the end of the actual transmission time be; and similar for an RX timestamp and figuring out its original length. So, this adds a new field to the duration routines which requests SIFS or no SIFS to be included. All the callers currently will call it requesting SIFS, so this /should/ be a glorious no-op. I'm however planning some future work around airtime fairness and positioning which requires these routines to have SIFS be optional. Notably though, the 11n version doesn't do any SIFS addition at the moment. I'll go and tweak and verify all of the packet durations before I go and flip that part on. Tested: * AR9330, STA mode * AR9330, AP mode * AR9380, STA mode Notes: svn path=/head/; revision=302877
* Replay r286410. Change KPI of how device drivers that provide wirelessGleb Smirnoff2015-08-272-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | connectivity interact with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=287197
* Revert the wifi ifnet changes until things are more baked and tested.Adrian Chadd2015-08-082-4/+8
| | | | | | | | | | | | * 286410 * 286413 * 286416 The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms. Notes: svn path=/head/; revision=286437
* Change KPI of how device drivers that provide wireless connectivity interactGleb Smirnoff2015-08-072-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the net80211 stack. Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it. Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details: - The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters. Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl. Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here: https://wiki.freebsd.org/projects/ifnet/net80211 Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated. Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix Notes: svn path=/head/; revision=286410
* Use device_printf() instead of if_printf(). No functional changes.Gleb Smirnoff2015-05-291-5/+8
| | | | Notes: svn path=/head/; revision=283744
* Cast everything to something longer than 32 bits so the sample maskAdrian Chadd2015-01-281-1/+1
| | | | | | | | | | | | | | | doesn't get truncated to 32 bits. Without this, 3x3 NICs transmitting at an MCS rate whose rix (rate index) in the rate table is > 31 end up returning errors, as the sample rate code doesn't think the rate is set in the rate table. Tested: * AR9380, STA, speaking 3x3 to an AP Notes: svn path=/head/; revision=277823
* Print out the final_rix if there's a problem.Adrian Chadd2015-01-281-2/+2
| | | | Notes: svn path=/head/; revision=277822
* The r48589 promised to remove implicit inclusion of if_var.h soon. PrepareGleb Smirnoff2013-10-261-0/+2
| | | | | | | | | | | to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h Sponsored by: Netflix Sponsored by: Nginx, Inc. Notes: svn path=/head/; revision=257176
* I give up - just throw the EWMA update into the normal update_stats()Adrian Chadd2013-02-271-105/+27
| | | | | | | | | | | | | routine. There were still corner cases where the EWMA update stats are being called on a rix which didn't have an intermediary stats update; thus no packets were counted against it. Sigh. This should fix the crashes I've been seeing on recent -HEAD. Notes: svn path=/head/; revision=247372
* Update the EWMA statistics for each intermediary rate as well as the finalAdrian Chadd2013-02-261-10/+33
| | | | | | | | | | | | | | | | | | rate. This fixes two things: * The intermediary rates now also have their EWMA values changed; * The existing code was using the wrong value for longtries - so the EWMA stats were only adjusted for the first rate and not subsequent rates in a MRR setup. TODO: * Merge the EWMA updates into update_stats() now.. Notes: svn path=/head/; revision=247317
* I've had some feedback that CCK rates are more reliable than MCS 0Adrian Chadd2012-10-311-0/+17
| | | | | | | | | | | | in some very degenerate conditions. However, until ath_rate_form_aggr() is taught to not form aggregates if ANY selected rate is non-MCS, this can't yet be enabled. So, just add a comment. Notes: svn path=/head/; revision=242392
* Improve performance of the Sample rate algorithm on 802.11n networks.Adrian Chadd2012-09-171-15/+5
| | | | | | | | | | | | | | | | | | * Don't treat high percentage failures as "sucessive failures" - high MCS rates are very picky and will quite happily "fade" from low to high failure % and back again within a few seconds. If they really don't work, the aggregate will just plain fail. * Only sample MCS rates +/- 3 from the current MCS. Sample will back off quite quickly, so there's no need to sample _all_ MCS rates between a high MCS rate and MCS0; there may be a lot of them. * Modify the smoothing rate to be 75% rather than 95% - it's more adaptive but it comes with a cost of being slightly less stable at times. A per-node, hysterisis behaviour would be nicer. Notes: svn path=/head/; revision=240583
* Improve the sample rate logging.Adrian Chadd2012-08-271-2/+3
| | | | Notes: svn path=/head/; revision=239756
* Fix buildKonstantin Belousov2012-08-151-2/+2
| | | | Notes: svn path=/head/; revision=239300
* Add a missing comma.Adrian Chadd2012-08-151-1/+1
| | | | | | | Pointy hat to: me, for not doing a 'clean' build first. Notes: svn path=/head/; revision=239286
* Add 3 stream rates to the sample rate control module.Adrian Chadd2012-08-151-1/+47
| | | | Notes: svn path=/head/; revision=239285
* Extend the sample mask from 32 bits to 64 bits.Adrian Chadd2012-08-152-19/+23
| | | | | | | | | | | This is required to support > MCS15 as more than 32 bit rate entries are suddenly available. This is quite messy - instead of doing typecasts at each mask operation, this should be migrated to use a macro and have that do the typecast. Notes: svn path=/head/; revision=239284
* Fix a case of "mis-located braces".Adrian Chadd2012-08-011-2/+2
| | | | | | | PR: kern/170302 Notes: svn path=/head/; revision=238962
* Allow 802.11n hardware to support multi-rate retry when RTS/CTS isAdrian Chadd2012-07-311-3/+9
| | | | | | | | | | | | | | | | | | | enabled. The legacy (pre-802.11n) hardware doesn't support this - although the AR5212 era hardware supports MRR, it doesn't have all the bits needed to support MRR + RTS/CTS. The AR5416 and later support a packet duration and RTS/CTS flags per rate scenario, so we should support it. Tested: * AR9280, STA PR: kern/170302 Notes: svn path=/head/; revision=238961
* Introduce a rate table TLV so rate table statistics consumersAdrian Chadd2012-07-201-24/+38
| | | | | | | know how to map rix -> rate code. Notes: svn path=/head/; revision=238638
* Bump this up to match what the HAL is at now.Adrian Chadd2012-07-201-1/+1
| | | | Notes: svn path=/head/; revision=238636
* Add a per-node rate control routine for each rate control module.Adrian Chadd2012-07-204-8/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For now, the only module implement is 'sample', and that's only partially implemented. The main issue here with reusing this structure in userland is that it uses 'rix' everywhere, which requires the userland code to have access to the current HAL rate table. For now, this is a very large work in progress. Specific details: * The rate control information is per-node at the moment and wrapped in a TLV, to ease parsing and backwards compatibility. * .. but so I can be slack for now, the userland statistics are just a copy of the kernel-land sample node state. * However, for now use a temporary copy and change the rix entries to dot11rate entries to make it slightly easier to eyeball. Problems: * The actual rate information table is unfortunately indexed by rix and it doesn't contain a rate code. So the userland side of this currently has no way to extract out a mapping. TODO: * Add a TLV payload to dump out the rate control table mapping so 'rix' can be turned into a dot11 / MCS rate. * .. then remove the temporary copy. Notes: svn path=/head/; revision=238633
* Prepare for (re)using this header file in userland.Adrian Chadd2012-07-201-0/+6
| | | | | | | | Remove the inlined code from the header file if it's compiled in userland. It's not required and it shouldn't be there in the first place. Notes: svn path=/head/; revision=238630
* In a complete lack of foresight on my part, my previous commit brokeAdrian Chadd2012-06-243-0/+3
| | | | | | | | | | | | | | | | | | | | | | the assumption that ath_softc doesn't change size based on build time configuration. I picked up on this because suddenly radar stuff didn't work; and although the ath_dfs code was setting sc_dodfs=1, the main ath driver saw sc_dodfs=0. So for now, include opt_ath.h in driver source files. This seems like the sane thing to do anyway. I'll have to do a pass over the code at some later stage and turn the radiotap TX/RX structs into malloc'ed memory, rather than in-line inside of ath_softc. I'd rather like to keep ath_softc the same layout regardless of configuration parameters. Pointy hat to: adrian Notes: svn path=/head/; revision=237529
* Add in some debugging code to check whether the current rate table hasAdrian Chadd2012-02-262-0/+26
| | | | | | | | | | | | | | | | | | | | | been bait-and-switched from the rate control code. This will avoid the panic that I saw and will avoid sending invalid rates (eg 11a/11g OFDM rates when in 11b, on 11b-only NICs (AR5211)) where the rate table is not "big". It also will point out situations where this occurs for the 11n NICs which will have sufficiently large rate tables that "invalid rix" doesn't occur. I'll try to follow this up with a commit that adds a current operating mode check. The "rix" is only relevant to the current operating mode and rate table. PR: kern/165475 Notes: svn path=/head/; revision=232170
* Fix the compile to work when IEEE80211_DEBUG isn't defined.Adrian Chadd2011-11-091-0/+2
| | | | | | | Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227371
* Introduce TX aggregation and software TX queue managementAdrian Chadd2011-11-084-126/+434
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros Notes: svn path=/head/; revision=227364
generated by cgit v1.3 (git 2.53.0) at 2026-04-03 13:37:39 +0000