Re: iwm(4) A-MSDU support
Hi Stefan,
just tested today with my other laptop (Dell Latitude 7400):
iwm0 at pci0 dev 20 function 3 "Intel Dual Band Wireless AC 9560" rev 0x30,
msix iwm0: hw rev 0x310, fw ver 34.3125811985.0, address 60:f2:62:06:61:f2
...against an Ubiquity UniFi AC AP Pro.
Before patch:
Up:
Conn: 1 Mbps: 24.859 Peak Mbps: 25.577 Avg Mbps: 24.859 8017
2932200 23.271 100.00%
Down:
Conn: 1 Mbps: 81.806 Peak Mbps: 87.146 Avg Mbps: 81.806
120168855968 70.848 100.00%
After patch:
Up:
Conn: 1 Mbps: 33.617 Peak Mbps: 33.617 Avg Mbps: 33.617
130763963176 31.674 100.00%
Down:
Conn: 1 Mbps: 87.707 Peak Mbps: 87.707 Avg Mbps: 87.707
8018 10584880 84.594 100.00%
Thanks for your work!
Uwe
> diff refs/heads/master refs/heads/amsdu
> blob - 00bf20b37ed33a652232885349c2f3dfa0d666d3
> blob + c353ee60473b7cfd237e1889e4a4b9235cb8bdc7
> --- sys/dev/pci/if_iwm.c
> +++ sys/dev/pci/if_iwm.c
> @@ -144,6 +144,8 @@
> #include
> #include
> #include
> +#include /* for SEQ_LT */
> +#undef DPRINTF /* defined in ieee80211_priv.h */
>
> #define DEVNAME(_s) ((_s)->sc_dev.dv_xname)
>
> @@ -328,12 +330,17 @@ int iwm_mimo_enabled(struct iwm_softc *);
> void iwm_setup_ht_rates(struct iwm_softc *);
> void iwm_htprot_task(void *);
> void iwm_update_htprot(struct ieee80211com *, struct ieee80211_node *);
> +void iwm_init_reorder_buffer(struct iwm_reorder_buffer *, uint16_t,
> + uint16_t);
> +void iwm_clear_reorder_buffer(struct iwm_softc *, struct iwm_rxba_data *);
> int iwm_ampdu_rx_start(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> void iwm_ampdu_rx_stop(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> +void iwm_rx_ba_session_expired(void *);
> +void iwm_reorder_timer_expired(void *);
> void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t,
> - uint16_t, uint16_t, int);
> + uint16_t, uint16_t, int, int);
> #ifdef notyet
> int iwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *,
> uint8_t);
> @@ -372,8 +379,10 @@ int iwm_rxmq_get_signal_strength(struct iwm_softc
> *, s
> void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *,
> struct iwm_rx_data *);
> int iwm_get_noise(const struct iwm_statistics_rx_non_phy *);
> +int iwm_rx_hwdecrypt(struct iwm_softc *, struct mbuf *, uint32_t,
> + struct ieee80211_rxinfo *);
> int iwm_ccmp_decap(struct iwm_softc *, struct mbuf *,
> - struct ieee80211_node *);
> + struct ieee80211_node *, struct ieee80211_rxinfo *);
> void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int,
> uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *);
> void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *,
> @@ -490,6 +499,20 @@ void iwm_nic_umac_error(struct iwm_softc *);
> #endif
> void iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, void *, size_t,
> struct mbuf_list *);
> +void iwm_flip_address(uint8_t *);
> +int iwm_detect_duplicate(struct iwm_softc *, struct mbuf *,
> + struct iwm_rx_mpdu_desc *, struct ieee80211_rxinfo *);
> +int iwm_is_sn_less(uint16_t, uint16_t, uint16_t);
> +void iwm_release_frames(struct iwm_softc *, struct ieee80211_node *,
> + struct iwm_rxba_data *, struct iwm_reorder_buffer *, uint16_t,
> + struct mbuf_list *);
> +int iwm_oldsn_workaround(struct iwm_softc *, struct ieee80211_node *,
> + int, struct iwm_reorder_buffer *, uint32_t, uint32_t);
> +int iwm_rx_reorder(struct iwm_softc *, struct mbuf *, int,
> + struct iwm_rx_mpdu_desc *, int, int, uint32_t,
> + struct ieee80211_rxinfo *, struct mbuf_list *);
> +void iwm_rx_mpdu_mq(struct iwm_softc *, struct mbuf *, void *, size_t,
> + struct mbuf_list *);
> int iwm_rx_pkt_valid(struct iwm_rx_packet *);
> void iwm_rx_pkt(struct iwm_softc *, struct iwm_rx_data *,
> struct mbuf_list *);
> @@ -2902,11 +2925,139 @@ iwm_setup_ht_rates(struct iwm_softc *sc)
> ic->ic_sup_mcs[1] = 0xff; /* MCS 8-15 */
> }
>
> +void
> +iwm_init_reorder_buffer(struct iwm_reorder_buffer *reorder_buf,
> +uint16_t ssn, uint16_t buf_size)
> +{
> + reorder_buf->head_sn = ssn;
> + reorder_buf->num_stored = 0;
> + reorder_buf->buf_size = buf_size;
> + reorder_buf->last_amsdu = 0;
> + reorder_buf->last_sub_index = 0;
> + reorder_buf->removed = 0;
> + reorder_buf->valid = 0;
> + reorder_buf->consec_oldsn_drops = 0;
> + reorder_buf->consec_oldsn_ampdu_gp2 = 0;
> + reorder_buf->consec_oldsn_prev_drop = 0;
> +}
> +
> +void
> +iwm_clear_reorder_buffer(struct iwm_softc *sc, struct iwm_rxba_data *rxba)
> +{
> + int i;
> + struct iwm_reorder_buffer *reorder_buf = >reorder_buf;
> + struct iwm_reorder_buf_entry *entry;
> +
> + for (i = 0; i <
Re: iwm(4) A-MSDU support
Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! > > ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, > the patch can neither be committed nor be put into snapshots!!! > > Our net80211 stack de-aggregates A-MSDUs in software. This works fine with > iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in > hardware and net80211 is currently unable to handle this. > > Our current iwm 9k code only works because long ago I disabled reception > of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs > working on 9k hardware is to add a bunch of driver-specific code which > handles de-aggregation. Otherwise, net80211 will drop frames which appear > to arrive out of order, or appear as duplicates even though they were > simply part of the same A-MSDU and thus share a sequence number. > The driver can re-order frames correctly based on information provided > by firmware. I'd rather implement this than letting these devices miss > out on A-MSDUs because the Rx speed advantage can be significant, around > 80/90 Mbps (but this will very much depend on the AP). > > If these A-* acronyms don't make sense and you'd like to know more, here > is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ > Note that we care about the nested case, which is also mentioned in this > article but not explained in detail. It's simply an A-MSDU stashed inside > an A-MPDU. If an AP can do 11AC, then it should support this. > > iwx(4) hardware has the same problem. > If this patch works fine on iwm(4) then I can port the changes to iwx(4), > do another round of testing, and eventually commit to both drivers at > the same time. > > Some of the changes below are based on code from the Linux iwlwifi driver. > I am not entirely happy with some of its style. But the code should be in > good enough shape to be tested. No regression noticed here for several days under my normal workload. iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi iwm0: hw rev 0x210, fw ver 17.3216344376.0, address dc:53:60:4a:b1:ea Tim.
Re: iwm(4) A-MSDU support
On 29 Mar 19:27, Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! > > ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, > the patch can neither be committed nor be put into snapshots!!! > > Our net80211 stack de-aggregates A-MSDUs in software. This works fine with > iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in > hardware and net80211 is currently unable to handle this. > > Our current iwm 9k code only works because long ago I disabled reception > of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs > working on 9k hardware is to add a bunch of driver-specific code which > handles de-aggregation. Otherwise, net80211 will drop frames which appear > to arrive out of order, or appear as duplicates even though they were > simply part of the same A-MSDU and thus share a sequence number. > The driver can re-order frames correctly based on information provided > by firmware. I'd rather implement this than letting these devices miss > out on A-MSDUs because the Rx speed advantage can be significant, around > 80/90 Mbps (but this will very much depend on the AP). > > If these A-* acronyms don't make sense and you'd like to know more, here > is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ > Note that we care about the nested case, which is also mentioned in this > article but not explained in detail. It's simply an A-MSDU stashed inside > an A-MPDU. If an AP can do 11AC, then it should support this. > > iwx(4) hardware has the same problem. > If this patch works fine on iwm(4) then I can port the changes to iwx(4), > do another round of testing, and eventually commit to both drivers at > the same time. > > Some of the changes below are based on code from the Linux iwlwifi driver. > I am not entirely happy with some of its style. But the code should be in > good enough shape to be tested. > Hi Stefan, I tested the patch with my: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address xx:xx:xx:xx:xx:xx against my Technicolor MediaAccess TG789vac. 5GHz: Down: Conn: 1 Mbps: 105.479 Peak Mbps: 107.955 Avg Mbps: 105.479 25076 13282504 106.366 100.00% Up: Conn: 1 Mbps: 28.056 Peak Mbps: 28.096 Avg Mbps: 28.056 17004 3483888 27.899 100.00% 2GHz: Down: Conn: 1 Mbps: 87.640 Peak Mbps: 87.965 Avg Mbps: 87.640 14041 11096024 88.680 100.00% UP: Conn: 1 Mbps: 22.786 Peak Mbps: 22.844 Avg Mbps: 22.786 9003 3176912 25.441 100.00% Thanks for your hard work! -- wq: ~uw
Re: iwm(4) A-MSDU support
On 2021 Mar 30 (Tue) at 20:22:09 +0200 (+0200), Stefan Sperling wrote: :On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote: :> Been running this for about 24 hours on my x395, seems to be good. :> :> Had only one stuck wifi when first trying it, but I was also stuck on a :> 2.4GHz channel and live in a dense apartment building. Forcing it to :> move to a 5GHz channel fixed it all up, and no problems since then. : :Understanding situations where it doesn't work is actually quite important. :Is it repeatable? And how big is the impact? :If you can fly somewhat in Minecraft on 2 GHz, and if it consistently :recovers after stuttering, I'd consider that success. : I can fly around pretty well in Minecraft while in 2 GHz, taking off is easy to do. However, when I go to a part of my apartment with dodgy wifi connectivity, I notice that my signal strength goes down to 23%, and I can't connect any more. I stay at HT-MCS15, even while it is flipping around trying to connect. if I try to ping the gateway I get the dreaded "ping: sendmsg: No buffer space available" error, until I down/up the interface. That does occasionally happen without this diff, so that is not a regression. No noticable packet loss in my testing, even on 2GHz during the busiest time of the day. :This is a huge change for the device you are using; all the Rx BA logic :is now handled by completely new code in the driver, with a bypass of the :corresponding logic in net80211. We now let the firmware move the BA :window forward and try to follow along, instead of maintaining our own :(duplicated) state of the Rx BA session. net80211 is only involved in :BA setup/teardown handshakes with the AP. : :In good conditions, I see virtually no packet loss. :I've tried testing error recovery by moving far out and back to the AP. :This seems to be OK. However, as with our net80211 Rx BA code we risk stuck :connections if the Rx BA window doesn't resync properly after packet loss. : :The logic implemented here is from Intel, with very few changes (such as :fixed timeout periods), so if the firmware and this new driver code work :reliably on Linux, it should also work fine for us. But I cannot be sure :that this code is free of bugs causing stuck connections. Like our net80211 :Rx BA code, this code will have to prove itself over time... : -- Misfortune, n.: The kind of fortune that never misses. -- Ambrose Bierce, "The Devil's Dictionary"
Re: iwm(4) A-MSDU support
On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote: > Been running this for about 24 hours on my x395, seems to be good. > > Had only one stuck wifi when first trying it, but I was also stuck on a > 2.4GHz channel and live in a dense apartment building. Forcing it to > move to a 5GHz channel fixed it all up, and no problems since then. Understanding situations where it doesn't work is actually quite important. Is it repeatable? And how big is the impact? If you can fly somewhat in Minecraft on 2 GHz, and if it consistently recovers after stuttering, I'd consider that success. This is a huge change for the device you are using; all the Rx BA logic is now handled by completely new code in the driver, with a bypass of the corresponding logic in net80211. We now let the firmware move the BA window forward and try to follow along, instead of maintaining our own (duplicated) state of the Rx BA session. net80211 is only involved in BA setup/teardown handshakes with the AP. In good conditions, I see virtually no packet loss. I've tried testing error recovery by moving far out and back to the AP. This seems to be OK. However, as with our net80211 Rx BA code we risk stuck connections if the Rx BA window doesn't resync properly after packet loss. The logic implemented here is from Intel, with very few changes (such as fixed timeout periods), so if the firmware and this new driver code work reliably on Linux, it should also work fine for us. But I cannot be sure that this code is free of bugs causing stuck connections. Like our net80211 Rx BA code, this code will have to prove itself over time...
Re: iwm(4) A-MSDU support
On 2021 Mar 29 (Mon) at 19:27:15 +0200 (+0200), Stefan Sperling wrote: :This patch attempts to add support for receiving A-MSDUs to iwm(4). :If you are using iwm(4) then please run with this patch and let me :know if it causes regressions. Thanks! : :ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, :the patch can neither be committed nor be put into snapshots!!! : :Our net80211 stack de-aggregates A-MSDUs in software. This works fine with :iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in :hardware and net80211 is currently unable to handle this. : :Our current iwm 9k code only works because long ago I disabled reception :of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs :working on 9k hardware is to add a bunch of driver-specific code which :handles de-aggregation. Otherwise, net80211 will drop frames which appear :to arrive out of order, or appear as duplicates even though they were :simply part of the same A-MSDU and thus share a sequence number. :The driver can re-order frames correctly based on information provided :by firmware. I'd rather implement this than letting these devices miss :out on A-MSDUs because the Rx speed advantage can be significant, around :80/90 Mbps (but this will very much depend on the AP). : :If these A-* acronyms don't make sense and you'd like to know more, here :is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ :Note that we care about the nested case, which is also mentioned in this :article but not explained in detail. It's simply an A-MSDU stashed inside :an A-MPDU. If an AP can do 11AC, then it should support this. : :iwx(4) hardware has the same problem. :If this patch works fine on iwm(4) then I can port the changes to iwx(4), :do another round of testing, and eventually commit to both drivers at :the same time. : :Some of the changes below are based on code from the Linux iwlwifi driver. :I am not entirely happy with some of its style. But the code should be in :good enough shape to be tested. : Been running this for about 24 hours on my x395, seems to be good. Had only one stuck wifi when first trying it, but I was also stuck on a 2.4GHz channel and live in a dense apartment building. Forcing it to move to a 5GHz channel fixed it all up, and no problems since then. iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix iwm0: hw rev 0x320, fw ver 34.3125811985.0, address 0c:dd:24:83:e1:40 -- Churchill's Commentary on Man: Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on.
Re: iwm(4) A-MSDU support
Hi Stefan, * Stefan Sperling wrote: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! Works so far fine with the following HW: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address 7c:2a:31:4d:1c:b9 Cheers Matthias
Re: iwm(4) A-MSDU support
Hi Stefan -- > Stefan Sperling writes: > > > This patch attempts to add support for receiving A-MSDUs to iwm(4). > > > > If you are using iwm(4) then please run with this patch and let me > > > > know if it causes regressions. Thanks! > All is good on my machine as well. iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xbb, msi iwm0: hw rev 0x140, fw ver 17.3216344376.0, address ac:fd:ce:09:87:97 Thanks! ~Brian
Re: iwm(4) A-MSDU support
On Mon, Mar 29, 2021 at 09:27:31PM +, Brian Callahan wrote: > Hi Stefan -- > > > Stefan Sperling writes: > > > > > This patch attempts to add support for receiving A-MSDUs to iwm(4). > > > > > > If you are using iwm(4) then please run with this patch and let me > > > > > > know if it causes regressions. Thanks! > > > > All is good on my machine as well. > > iwm0 at pci4 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0xbb, msi > iwm0: hw rev 0x140, fw ver 17.3216344376.0, address ac:fd:ce:09:87:97 > > Thanks! > > ~Brian Running all day without issue. iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi iwm0: hw rev 0x230, fw ver 34.0.1, address cc:2f:71:9f:86:7a -- Tracey Emery
Re: iwm(4) A-MSDU support
Stefan Sperling writes: > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! Been running your diff on a workstation the past 2 hours with no noticeable regressions. iwm0 at pci13 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi iwm0: hw rev 0x140, fw ver 17.3216344376.0, address 7c:5c:f8:f0:40:2e -dv
Re: iwm(4) A-MSDU support
Hello! s...@stsp.name (Stefan Sperling), 2021.03.29 (Mon) 19:27 (CEST): > This patch attempts to add support for receiving A-MSDUs to iwm(4). > If you are using iwm(4) then please run with this patch and let me > know if it causes regressions. Thanks! no regressions with: iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 8260" rev 0x3a, msi iwm0: hw rev 0x200, fw ver 34.0.1, address 34:f3:9a:xx:yy:zz thanks for all your work on wifi! Marcus OpenBSD 6.9-beta (GENERIC.MP) #1: Mon Mar 29 20:50:53 CEST 2021 me@myself:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7944069120 (7576MB) avail mem = 7687913472 (7331MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb7058000 (65 entries) bios0: vendor LENOVO version "N1CET81W (1.49 )" date 06/04/2020 bios0: LENOVO 20FAS06G00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1596.94 MHz, 06-4e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 1435.78 MHz, 06-4e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 2 (EXP1) acpiprt5 at acpi0: bus -1 (EXP2) acpiprt6 at acpi0: bus 4 (EXP3) acpiprt7 at acpi0: bus -1 (EXP5) acpiprt8 at acpi0: bus -1 (RP09) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "00HW023" serial 605 type LiP oem "SMP" acpibat1 at acpi0: BAT1 model "01AV462" serial 125 type LiP oem "SMP" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 2.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI acpipwrres1 at acpi0: PG00, resource for PEG0 acpipwrres2 at acpi0: PG01, resource for PEG1 acpipwrres3 at acpi0: PG02, resource for PEG2 acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpitz0 at acpi0: critical temperature is 128 degC acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 1596 MHz: speeds: 2701, 2700, 2600, 2500, 2300, 2100, 1900, 1800, 1600, 1400, 1300, 1100, 800, 700, 600, 400 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 6G Host" rev 0x08 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 520" rev 0x07 drm0 at inteldrm0 inteldrm0: msi, SKYLAKE, gen 9 "Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured xhci0 at pci0 dev 20 function 0 "Intel 100 Series xHCI" rev 0x21: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 pchtemp0 at pci0 dev 20 function 2 "Intel 100 Series Thermal" rev 0x21
iwm(4) A-MSDU support
This patch attempts to add support for receiving A-MSDUs to iwm(4). If you are using iwm(4) then please run with this patch and let me know if it causes regressions. Thanks! ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason, the patch can neither be committed nor be put into snapshots!!! Our net80211 stack de-aggregates A-MSDUs in software. This works fine with iwm 7k and 8k devices. However, iwm 9k devices de-aggregate A-MSDUs in hardware and net80211 is currently unable to handle this. Our current iwm 9k code only works because long ago I disabled reception of A-MSDUs for all devices. Unfortunately, the only way to get A-MSDUs working on 9k hardware is to add a bunch of driver-specific code which handles de-aggregation. Otherwise, net80211 will drop frames which appear to arrive out of order, or appear as duplicates even though they were simply part of the same A-MSDU and thus share a sequence number. The driver can re-order frames correctly based on information provided by firmware. I'd rather implement this than letting these devices miss out on A-MSDUs because the Rx speed advantage can be significant, around 80/90 Mbps (but this will very much depend on the AP). If these A-* acronyms don't make sense and you'd like to know more, here is a fairly good explanation: https://mrncciew.com/2013/04/11/a-mpdu-a-msdu/ Note that we care about the nested case, which is also mentioned in this article but not explained in detail. It's simply an A-MSDU stashed inside an A-MPDU. If an AP can do 11AC, then it should support this. iwx(4) hardware has the same problem. If this patch works fine on iwm(4) then I can port the changes to iwx(4), do another round of testing, and eventually commit to both drivers at the same time. Some of the changes below are based on code from the Linux iwlwifi driver. I am not entirely happy with some of its style. But the code should be in good enough shape to be tested. diff refs/heads/master refs/heads/amsdu blob - 00bf20b37ed33a652232885349c2f3dfa0d666d3 blob + c353ee60473b7cfd237e1889e4a4b9235cb8bdc7 --- sys/dev/pci/if_iwm.c +++ sys/dev/pci/if_iwm.c @@ -144,6 +144,8 @@ #include #include #include +#include /* for SEQ_LT */ +#undef DPRINTF /* defined in ieee80211_priv.h */ #define DEVNAME(_s)((_s)->sc_dev.dv_xname) @@ -328,12 +330,17 @@ int iwm_mimo_enabled(struct iwm_softc *); void iwm_setup_ht_rates(struct iwm_softc *); void iwm_htprot_task(void *); void iwm_update_htprot(struct ieee80211com *, struct ieee80211_node *); +void iwm_init_reorder_buffer(struct iwm_reorder_buffer *, uint16_t, + uint16_t); +void iwm_clear_reorder_buffer(struct iwm_softc *, struct iwm_rxba_data *); intiwm_ampdu_rx_start(struct ieee80211com *, struct ieee80211_node *, uint8_t); void iwm_ampdu_rx_stop(struct ieee80211com *, struct ieee80211_node *, uint8_t); +void iwm_rx_ba_session_expired(void *); +void iwm_reorder_timer_expired(void *); void iwm_sta_rx_agg(struct iwm_softc *, struct ieee80211_node *, uint8_t, - uint16_t, uint16_t, int); + uint16_t, uint16_t, int, int); #ifdef notyet intiwm_ampdu_tx_start(struct ieee80211com *, struct ieee80211_node *, uint8_t); @@ -372,8 +379,10 @@ intiwm_rxmq_get_signal_strength(struct iwm_softc *, s void iwm_rx_rx_phy_cmd(struct iwm_softc *, struct iwm_rx_packet *, struct iwm_rx_data *); intiwm_get_noise(const struct iwm_statistics_rx_non_phy *); +intiwm_rx_hwdecrypt(struct iwm_softc *, struct mbuf *, uint32_t, + struct ieee80211_rxinfo *); intiwm_ccmp_decap(struct iwm_softc *, struct mbuf *, - struct ieee80211_node *); + struct ieee80211_node *, struct ieee80211_rxinfo *); void iwm_rx_frame(struct iwm_softc *, struct mbuf *, int, uint32_t, int, int, uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *); void iwm_rx_tx_cmd_single(struct iwm_softc *, struct iwm_rx_packet *, @@ -490,6 +499,20 @@ void iwm_nic_umac_error(struct iwm_softc *); #endif void iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, void *, size_t, struct mbuf_list *); +void iwm_flip_address(uint8_t *); +intiwm_detect_duplicate(struct iwm_softc *, struct mbuf *, + struct iwm_rx_mpdu_desc *, struct ieee80211_rxinfo *); +intiwm_is_sn_less(uint16_t, uint16_t, uint16_t); +void iwm_release_frames(struct iwm_softc *, struct ieee80211_node *, + struct iwm_rxba_data *, struct iwm_reorder_buffer *, uint16_t, + struct mbuf_list *); +intiwm_oldsn_workaround(struct iwm_softc *, struct ieee80211_node *, + int, struct iwm_reorder_buffer *, uint32_t, uint32_t); +intiwm_rx_reorder(struct iwm_softc *, struct mbuf *, int, + struct iwm_rx_mpdu_desc *, int, int, uint32_t, + struct ieee80211_rxinfo *, struct mbuf_list *); +void iwm_rx_mpdu_mq(struct iwm_softc *, struct mbuf *, void *,
