rtwn: explicitly configure RTS based on basic rates

The NIC/firmware initialises the initial RTS/CTS rate to something
high, like OFDM48. That's not going to be very reliable.

It's not a problem r

rtwn: explicitly configure RTS based on basic rates

The NIC/firmware initialises the initial RTS/CTS rate to something
high, like OFDM48. That's not going to be very reliable.

It's not a problem right now as we program in the RTS/CTS value
to use in the TX descriptor setup path based on the control rate
for the given frame TX rate, and like the INIDATA/driver rate
stuff in the TX descriptor, the TX descriptor RTS/CTS rate overrides
the INIRTS rate.

However when it's time to flip on firmware based rate control,
the initial rate needs to not be OFDM48. Yes, the firmware and
hardware does have some rate retry schedule for RTS/CTS frames,
but there's no point in wasting short retries trying to do OFDM48
based RTS/CTS setup.

Add some warning logging if there are no basic or RTS/CTS rates
available, and leave things at default. If this happens in
production for someone then it would be good to know and what
the rate mask was.

Locally tested:

* RTL8192CU, STA mode (with/without firmware rate control enabled locally)

Differential Revision: https://reviews.freebsd.org/D48140

show more ...

rtwn: make sure RCR_APPFCS stays set in monitor mode / mode changes.

My previous commit meant that APPFCS wasn't enabled during monitor
mode and likely other corner cases.

Ensure it stays on at all

rtwn: make sure RCR_APPFCS stays set in monitor mode / mode changes.

My previous commit meant that APPFCS wasn't enabled during monitor
mode and likely other corner cases.

Ensure it stays on at all times.

This, amusingly, fixes monitor mode in RTL8812AU/RTL8821AU - without it,
I don't see HT/VHT frames in monitor mode but I can still receive them
in normal STA mode.

Differential Revision: https://reviews.freebsd.org/D48112

show more ...

rtwn: add a default OFDM / CCK rate for self-generated frames

I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This i

rtwn: add a default OFDM / CCK rate for self-generated frames

I noticed during testing that the MAC was generating MCS7 ACKs and
MCS7 block-ACK frames in response to MCS frames from its peer.
This is very suboptimal - it means that unless you're very close
to your peer (in this case a 2GHz AP), you'll end up failing a lot
of ACKs.

Linux faced the opposite problem in rtl8xxxu - the rate set being
programmed in here included a lot MORE rates, including MCS 0->7
and OFDM 6M->54M. This meant that they were INTENTIONALLY telling
the hardware to transmit at higher rates, and their fix was to
mask out the higher rates so self-generated frames don't try the
high rates at all.

Now, I am not sure why I'm not seeing any OFDM or HT basic rates.
We don't mark any OFDM / HT rates as basic in net80211 (in
ieee80211_phy.c) so I'm going to need to go and do a review of the
standard to see what's up. Additionally, the HT rate set that we
populate isn't tagging any of the HT rates as IEEE80211_RATE_BASIC,
so the code I added for now is a no-op.

So:

* Extend rtwn_get_rates() and its consumers to populate the HT rateset
with basic rates if they're provided
* Add a default 2GHz / 5GHz mask, inspired by linux, applied over the
basic rates provided.
* Make sure there's at least an OFDM rate (for 2G/5G) rate available if
the peer node is HT, which avoids the MAC defaulting to MCS7 when
generating ACK/block-ACK.
* Add register definitions for INIDATA/INIRTS, which set the default
data rate when the driver doesn't specify the initial data / RTS/CTS
rates in the TX descriptor.
* Leave a comment about why I've modified the mask from Linux.

Locally tested:

* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8192EU, STA mode
* RTL8812AU, STA mode

Differential Revision: https://reviews.freebsd.org/D48019
Reviewed by: bz

show more ...

rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates

The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.

So, break out the leg

rtwn: update rtwn_get_rates() to separate out the CCK/OFDM and HT rates

The 32 bit bitmap is enough for CCK/OFDM rates and MCS0..15, but
won't work for > MCS15, nor VHT rates.

So, break out the legacy rates and HT rates.

* break the rates and htrates out
* document which calls are looking up basic rates and which care
about the rates themselves
* ensure the rate bitmap passed into the rate control firmware call
(which isn't enabled yet!) is capped at 28 bits so they don't
set the mode field.

Differential Revision: https://reviews.freebsd.org/D47993
Reviewed by: bz, imp

show more ...

rtwn: don't do 64 bit TSF extension by default

The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. The

rtwn: don't do 64 bit TSF extension by default

The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. They take up valuable USB link time.

It's likely much less expensive for PCIe adapters. At some point
it may be worthwhile enabling it by default just for those.

With this disabled, the only USB traffic that I see during
normal data operation are bulk TX/RX data transfers for 802.11
packets, and on NICs w/ net80211 rate control, the control register
space read/writes for TX completion. (And that will also need
addressing.)

This is the difference between 15mbit TCP RX and 30mbit TCP RX
on the 11n NICs, and around 40 to 50mbit TCP RX on the 11ac NICs
in HT40 and VHT80.

Locally tested:

* RTL8188EU, STA mode
* RTL8192CU, STA mode
* RTL8192EU, STA mode
* RTL8811AU, STA mode
* RTL8821AU, STA mode

Differential Revision: https://reviews.freebsd.org/D47861

show more ...

rtwn: enable FCS in the recive config to work around truncated frames

I noticed that on RTL8812AU/RTL8821AU receiving VHT frames that
I'd occasionally see frames missing the last 4 bytes. I can
eas

rtwn: enable FCS in the recive config to work around truncated frames

I noticed that on RTL8812AU/RTL8821AU receiving VHT frames that
I'd occasionally see frames missing the last 4 bytes. I can
easily reproduce it with a ping sweep and fast (10ms) between frames.

There's also a report of an earlier NIC (RTL8188EU) doing the same
thing with HT frames but not with OFDM (11g) frames.

After a bunch of poking, it turns out a driver where things DID work
properly for the other report kept FCS enabled, and trimmed it from
the frame before pushing it up to the network layer.

I did the same and it also worked fine.

The other solution was to disable PHYSTATUS notifications, but then
we'd get no per packet RX notifications (RX rate, RSSI, etc.)

Locally tested:

* RTL8192EU, STA mode (HT)
* RTL8812AU, STA mode (HT, VHT)
* RTL8821AU, STA mode (HT, VHT)

Differential Revision: https://reviews.freebsd.org/D47775

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

rtwn: clean up empty lines in .c and .h files

Convert to if_foreach_llmaddr() KPI.

ifnet: Replace if_addr_lock rwlock with epoch + mutex

Run on LLNW canaries and tested by pho@

gallatin:
Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5
based ConnectX 4-LX NIC, I

ifnet: Replace if_addr_lock rwlock with epoch + mutex

Run on LLNW canaries and tested by pho@

gallatin:
Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5
based ConnectX 4-LX NIC, I see an almost 12% improvement in received
packet rate, and a larger improvement in bytes delivered all the way
to userspace.

When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1,
I see, using nstat -I mce0 1 before the patch:

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32
4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32
4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32
4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32
4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32
4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32
4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32

After the patch

InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51
5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51
5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51
5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51
5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52
5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52

Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch

Reviewed by: gallatin
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15366

show more ...

MFH @ r323558.

MFhead@r323343

rtwn(4): some initial preparations for (basic) VHT support.

Rename RTWN_RIDX_MCS to RTWN_RIDX_HT_MCS before adding 802.11ac
MCS rate indexes (they have different offset).

No functional change inten

rtwn(4): some initial preparations for (basic) VHT support.

Rename RTWN_RIDX_MCS to RTWN_RIDX_HT_MCS before adding 802.11ac
MCS rate indexes (they have different offset).

No functional change intended.

show more ...

MFhead@r320180

Merge ^/head r319973 through 321382.

Merge ^/head r320573 through r320970.

rtwn: add Rx descriptor structures for common code.

Remove any chipset specific usage of Rx descriptor structure / bits
from common code to prevent misuse of fields that may differ
between various c

rtwn: add Rx descriptor structures for common code.

Remove any chipset specific usage of Rx descriptor structure / bits
from common code to prevent misuse of fields that may differ
between various chipsets.

Checked with: RTL8821AU in STA mode.

show more ...

MFhead@r313243

Merge ^/head r312309 through r312623.

rtwn: export more stats to net80211

Setup more ieee80211_rx_stats fields for received frames:
- pktflags:
* IEEE80211_RX_F_FAIL_FCSCRC;
* IEEE80211_RX_F_AMPDU;
* IEEE80211_RX_F_AMPDU_MORE;

rtwn: export more stats to net80211

Setup more ieee80211_rx_stats fields for received frames:
- pktflags:
* IEEE80211_RX_F_FAIL_FCSCRC;
* IEEE80211_RX_F_AMPDU;
* IEEE80211_RX_F_AMPDU_MORE;
* IEEE80211_RX_F_SHORTGI;
- rate flags (CCK, OFDM, HT);
- width;
- phytype;
- rate;
- rx_tsf;
- rssi;
- nf;
- ieee, freq (RTL8188EU only, when ht40 support is disabled).

Tested with:
- RTL8188CE, RTL8188EU, RTL8821AU (STA / AP modes, i386)
- (by kevlo) RTL8188EU and RTL8812AU (amd64)

Reviewed by: adrian (previous version), kevlo
Differential Revision: https://reviews.freebsd.org/D9021

show more ...

Merge ^/head r308227 through r308490.

rtwn: fix Rx filter setup for some multi-vap configuratons.

- Correctly refresh Rx filter when AP (IBSS) vap is created after STA vap.
- Block any RCR updates during TSF correction (IBSS mode).
- Se

rtwn: fix Rx filter setup for some multi-vap configuratons.

- Correctly refresh Rx filter when AP (IBSS) vap is created after STA vap.
- Block any RCR updates during TSF correction (IBSS mode).
- Set CBSSID* bits during vap creation, not when it was started / stopped.
- Cache current state to prevent unnecessary register reads.

Tested with RTL8188CE, STA + AP mode.

show more ...

Merge ^/head r307383 through r307735.

rtwn(4), urtwn(4): merge common code, add support for 11ac devices.

All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- m

rtwn(4), urtwn(4): merge common code, add support for 11ac devices.

All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- multi-bss support:
* for RTL8821AU: 2 VAPs at the same time;
* other: 1 any VAP + 1 sta VAP.
RTL8188CE:
- fix IQ calibration bug (reason of significant speed degradation);
- add h/w crypto acceleration support.
USB:
- A-MPDU Tx support;
- short GI support;
Other:
- add support for RTL8812AU / RTL8821AU chipsets
(a/b/g/n only; no ac yet);
- split merged code into subparts:
* bus glue (usb/*, pci/*, rtl*/usb/*, rtl*/pci/*)
* common (if_rtwn*)
* chip-specific (rtl*/*)
- various other bugfixes.

Due to code reorganization, module names / requirements were changed too:
urtwn urtwnfw -> rtwn rtwn_usb rtwnfw
rtwn rtwnfw -> rtwn rtwn_pci rtwnfw

Tested with RTL8188CE, RTL8188CUS, RTL8188EU and RTL8821AU.

Tested by: kevlo, garga,
Peter Garshtja <peter.garshtja@ambient-md.com>,
Kevin McAleavey <kevin.mcaleavey@knosproject.com>,
Ilias-Dimitrios Vrachnis <id@vrachnis.com>,
<otacilio.neto@bsd.com.br>
Relnotes: yes

show more ...