From: Kalle Valo <kvalo@kernel.org>
To: Baochen Qiang <quic_bqiang@quicinc.com>
Cc: <ath12k@lists.infradead.org>, <linux-wireless@vger.kernel.org>,
<kernel@quicinc.com>, <netdev@vger.kernel.org>
Subject: Re: [PATCH] wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850
Date: Thu, 01 Aug 2024 18:07:58 +0300 [thread overview]
Message-ID: <87ed788enl.fsf@kernel.org> (raw)
In-Reply-To: <20240715023814.20242-1-quic_bqiang@quicinc.com> (Baochen Qiang's message of "Mon, 15 Jul 2024 10:38:14 +0800")
Baochen Qiang <quic_bqiang@quicinc.com> writes:
> In transmit path, it is likely that the iova is not aligned to PCIe TLP
> max payload size, which is 128 for WCN7850. Normally in such cases hardware
> is expected to split the packet into several parts in a manner such that
> they, other than the first one, have aligned iova. However due to hardware
> limitations, WCN7850 does not behave like that properly with some specific
> unaligned iova in transmit path. This easily results in target hang in a
> KPI transmit test: packet send/receive failure, WMI command send timeout
> etc. Also fatal error seen in PCIe level:
>
> ...
> Capabilities: ...
> ...
> DevSta: ... FatalErr+ ...
> ...
> ...
>
> Work around this by manually moving/reallocating payload buffer such that
> we can map it to a 128 bytes aligned iova. The moving requires sufficient
> head room or tail room in skb: for the former we can do ourselves a favor
> by asking some extra bytes when registering with mac80211, while for the
> latter we can do nothing.
>
> Moving/reallocating buffer consumes additional CPU cycles, but the good news
> is that an aligned iova increases PCIe efficiency. In my tests on some X86
> platforms the KPI results are almost consistent.
>
> Since this is seen only with WCN7850, add a new hardware parameter to
> differentiate from others.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
>
> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
[...]
> --- a/drivers/net/wireless/ath/ath12k/dp_tx.c
> +++ b/drivers/net/wireless/ath/ath12k/dp_tx.c
> @@ -162,6 +162,60 @@ static int ath12k_dp_prepare_htt_metadata(struct sk_buff *skb)
> return 0;
> }
>
> +static void ath12k_dp_tx_move_payload(struct sk_buff *skb,
> + unsigned long delta,
> + bool head)
> +{
> + unsigned long len = skb->len;
> +
> + if (head) {
> + skb_push(skb, delta);
> + memmove(skb->data, skb->data + delta, len);
> + skb_trim(skb, len);
> + } else {
> + skb_put(skb, delta);
> + memmove(skb->data + delta, skb->data, len);
> + skb_pull(skb, delta);
> + }
> +}
I'm nitpicking, but usually booleans like the head variable here don't
help with readability. Having two separate functions would be easier to
read, but this is fine as it's so small.
> @@ -279,6 +334,23 @@ int ath12k_dp_tx(struct ath12k *ar, struct ath12k_vif *arvif,
> goto fail_remove_tx_buf;
> }
>
> + if (iova_mask &&
> + (unsigned long)skb->data & iova_mask) {
> + ret = ath12k_dp_tx_align_payload(ab, &skb);
> + if (ret) {
> + dev_warn_once(ab->dev, "failed to align TX buffer %d\n", ret);
Why dev_warn_once()? I changed it to ath12k_warn() in the pending
branch.
> --- a/drivers/net/wireless/ath/ath12k/hw.h
> +++ b/drivers/net/wireless/ath/ath12k/hw.h
> @@ -96,6 +96,8 @@
> #define ATH12K_M3_FILE "m3.bin"
> #define ATH12K_REGDB_FILE_NAME "regdb.bin"
>
> +#define PCIE_MAX_PAYLOAD_SIZE 128
PCIE prefix implies that this is in PCI subsystem. I renamed it to
ATH12K_PCIE_MAX_PAYLOAD_SIZE.
Please check my changes:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=b603c1e0d94fb1eb0576ef48ebe37c8c1ce86328
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2024-08-01 15:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 2:38 [PATCH] wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850 Baochen Qiang
2024-07-19 13:07 ` Mark Pearson
2024-08-01 15:20 ` Kalle Valo
2024-07-19 14:10 ` Jeff Johnson
2024-07-22 6:54 ` Baochen Qiang
2024-07-22 7:02 ` Baochen Qiang
2024-08-01 15:22 ` Kalle Valo
2024-08-01 15:07 ` Kalle Valo [this message]
2024-08-01 18:04 ` Jeff Johnson
2024-08-05 9:36 ` Kalle Valo
2024-08-05 3:20 ` Baochen Qiang
2024-08-05 9:28 ` Kalle Valo
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=87ed788enl.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath12k@lists.infradead.org \
--cc=kernel@quicinc.com \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quic_bqiang@quicinc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.