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
Date: Mon, 04 Apr 2022 10:15:15 +0300 [thread overview]
Message-ID: <87v8vps4jg.fsf@kernel.org> (raw)
In-Reply-To: <20220402153615.9593-1-ryazanov.s.a@gmail.com> (Sergey Ryazanov's message of "Sat, 2 Apr 2022 18:36:12 +0300")
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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2022-04-04 7:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-02 15:36 [PATCH RFC 0/3] ath10k: add encapsulation offloading support Sergey Ryazanov
2022-04-02 15:36 ` [PATCH RFC 1/3] ath10k: improve tx status reporting Sergey Ryazanov
2022-04-02 15:36 ` [PATCH RFC 2/3] ath10k: turn rawmode into frame_mode Sergey Ryazanov
2022-04-02 16:01 ` [PATCH RFC 3/3] ath10k: add encapsulation offloading support Sergey Ryazanov
2022-04-04 7:15 ` Kalle Valo [this message]
2022-04-18 15:42 ` [PATCH RFC 0/3] " Sergey Ryazanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8vps4jg.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=ryazanov.s.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).