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;
MIME-Version: 1.0
References: <20220402153615.9593-1-ryazanov.s.a@gmail.com> <87v8vps4jg.fsf@kernel.org>
In-Reply-To: <87v8vps4jg.fsf@kernel.org>
From:   Sergey Ryazanov <ryazanov.s.a@gmail.com>
Date:   Mon, 18 Apr 2022 18:42:39 +0300
Message-ID: <CAHNKnsSbjD_ok+qxj4=HnyNCEKWey34xNQwZwe1gYCKwYmxtAw@mail.gmail.com>
Subject: Re: [PATCH RFC 0/3] ath10k: add encapsulation offloading support
To:     linux-wireless@vger.kernel.org
Cc:     ath10k@lists.infradead.org, Kalle Valo <kvalo@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Apr 4, 2022 at 10:15 AM Kalle Valo <kvalo@kernel.org> wrote:
> 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?

Is any brave tester trying to improve the performance of their system
with this change? Can I resend it as a regular patch?

-- 
Sergey