On Mon, Apr 4, 2022 at 10:15 AM Kalle Valo <kvalo@xxxxxxxxxx> wrote: > Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx> writes: >> 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 three patches, the first two 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 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 third 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 and works well, >> but it may introduces some regression for other untested chips. So the >> series is just an RFC for now. > > This looks very good to me. But the testing part concerns me as well, it > would be good to have some quick testing at least with QCA6174/QCA9377 > PCI devices to make sure we don't break those. Preferably also > QCA6174/QCA9377 SDIO devices should be tested, they work somewhat > differently. Can anyone help? Is any brave tester trying to improve the performance of their system with this change? Can I resend it as a regular patch? -- Sergey
