Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Kalle Valo <kvalo@kernel.org>
To:     Sergey Ryazanov <ryazanov.s.a@gmail.com>
Cc:     ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH RFC 0/3] ath10k: add encapsulation offloading support
References: <20220402153615.9593-1-ryazanov.s.a@gmail.com>
Date:   Mon, 04 Apr 2022 10:15:15 +0300
In-Reply-To: <20220402153615.9593-1-ryazanov.s.a@gmail.com> (Sergey Ryazanov's
        message of "Sat, 2 Apr 2022 18:36:12 +0300")
Message-ID: <87v8vps4jg.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Sergey Ryazanov <ryazanov.s.a@gmail.com> 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?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches