| Message ID | 20220516032519.29831-1-ryazanov.s.a@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ath10k: add encapsulation offloading support | expand |
Hello, I confirm now my QCA9377 pci module has no regressions in either modes with these patches I was able to test it as an AP and it worked under ETHERNET mode without any obvious regressions but I'm unable to check maximum throughput My hardware info from dmesg and tested on kernel 5.17.7 qca9377 hw1.0 target 0x05020000 chip_id 0x003820ff sub 11ad:0806 firmware ver WLAN.TF.2.1-00021-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 42e41877 My quoted statement of a possible regression seems to have been my old CPU acting up and is ok to remove On Sun, May 15, 2022 at 10:25 PM Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote: > > Hello, > > this series introduces driver support for hardware encapsulation > offloading feature. > > The main goal of the series is an overall improvement of system > performance. On a QCA9563+QCA9888-based access point in bridged mode, > encapsulation offloading increases TCP 16-streams DL throughput from > 365 to 396 mbps (+8%) and UDP DL throughput from 436 to 483 mbps (+11%). > > The series consist of four patches, the first three prepare the code, > and the last one introduces the offloading support itself. The first > patch reworks transmission status reporting to make it flexible enough > to support 802.11 and Ethernet encapsulated frames reporting. The second > patch reworks improves Ethernet encapsulated frames handling in the HTT > Tx layer. The third patch reworks the module parameter that configures > the main encapsulation format of frames that are passed from the driver > to the hardware. It makes it possible to configure more encapsulation > methods than just raw or not-raw. And, as stated before, the fourth > patch actually introduces offloading support. It changes a couple of > frame analysis places along the xmit path and starts reporting > offloading support to mac80211 via the corresponding hw attribute. > > The new feature has been extensively tested with QCA9888. It works well > and introduces a measurable performance increase on platforms with not > so fast CPU (e.g. QCA9563). Tests with MT7621+QCA6174 show no > regression. I was unable to observe any measurable throughput increase > in tests with QCA6174 due to the poor perfomance the SISO client and OTA > testing. Only slight downlink rate stability increase with slight > reducing of the SIRQ load on the AP side. > > Tests with QCA9880, QCA9980, QCA9984, QCA9377 revealed no regression > [1]. No specific throughput tests have been performed. In OTA tests with > a regular load, there is a slight increase in througput stability. > > In tests of the QCA9377 in Sta mode, Edward Matijevic noticed a possible > regression in the Ethernet tx mode compared to the Native WiFi tx > mode: > > There might be a regression in download bandwidth under ETHERNET mode > > but I didn't do enough tests to see if was my PC or the adapter as the > > upload bandwidth was similar to other tests. > > NATIVE_WIFI performs the same as without the patch. > > Credits: thanks to OpenWrt folks Oldřich Jedlička > <oldium.pro@gmail.com> and Edward Matijevic <motolav@gmail.com> who > helped me a lot to perform extensive testing with various chips after a > RFC/RFT post in the OpenWrt development mailing list [1]. Thanks to > Zhijun You <hujy652@gmail.com> who helped with the testing, pointed me > to the previous work (see below) and the missed parts in the HTT Tx > layer [1]. > > Prior work: similar patches were independently developed by QCA and then > submitted for inclusion by John Crispin <john@phrozen.org> [2] and > latter by Zhijun You <hujy652@gmail.com> [3]. The work was not merged > due to the lack of a part for 64-bits descriptors [4]. The idea of HTT > Tx layer change from this work was adopted for the series in patch #2. > > 1. https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg62013.html > 2. https://lore.kernel.org/all/20191216092207.31032-1-john@phrozen.org/ > 3. https://lore.kernel.org/all/20210524103130.66693-1-hujy652@gmail.com/ > 4. https://patchwork.kernel.org/project/linux-wireless/patch/20191216092207.31032-1-john@phrozen.org/ > > CC: Edward Matijevic <motolav@gmail.com> > CC: John Crispin <john@phrozen.org> > CC: Oldřich Jedlička <oldium.pro@gmail.com> > CC: Tom Psyborg <pozega.tomislav@gmail.com> > CC: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> > CC: Zhijun You <hujy652@gmail.com> > > Changes since RFC: > * new Tested-on and Tested-by tags > * new patch #2 for better Ethernet encapsulation support in the HTT Tx > layer > * rebased on top of latest ath-next > > Sergey Ryazanov (3): > ath10k: improve tx status reporting > ath10k: htt_tx: do not interpret Eth frames as WiFi > ath10k: turn rawmode into frame_mode > ath10k: add encapsulation offloading support > > drivers/net/wireless/ath/ath10k/core.c | 11 ++-- > drivers/net/wireless/ath/ath10k/core.h | 1 + > drivers/net/wireless/ath/ath10k/htt_tx.c | 61 ++++++++++++--------- > drivers/net/wireless/ath/ath10k/mac.c | 67 +++++++++++++++++++----- > drivers/net/wireless/ath/ath10k/txrx.c | 12 ++++- > 5 files changed, 108 insertions(+), 44 deletions(-) > > -- > 2.35.1 >
Hello Edward, On Tue, May 17, 2022 at 5:37 AM Edward Matijevic <motolav@gmail.com> wrote: > Hello, > I confirm now my QCA9377 pci module has no regressions in either modes > with these patches > I was able to test it as an AP and it worked under ETHERNET mode > without any obvious regressions but I'm unable to check maximum > throughput > > My hardware info from dmesg and tested on kernel 5.17.7 > qca9377 hw1.0 target 0x05020000 chip_id 0x003820ff sub 11ad:0806 > firmware ver WLAN.TF.2.1-00021-QCARMSWP-1 api 6 features > wowlan,ignore-otp crc32 42e41877 > > My quoted statement of a possible regression seems to have been my old > CPU acting up and is ok to remove Thank you for the update.