From: Kalle Valo <kvalo@codeaurora.org>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: Alagu Sankar <alagusankar@silex-india.com>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 3/6] ath10k: sdio: read RX packets in bundles
Date: Fri, 12 Apr 2019 16:08:37 +0300 [thread overview]
Message-ID: <874l73e5gq.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20190409190851.4557-4-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Tue, 9 Apr 2019 21:08:48 +0200")
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> From: Alagu Sankar <alagusankar@silex-india.com>
>
> The existing implementation of initiating multiple sdio transfers for
> receive bundling is slowing down the receive speed.
>
> Instead of having one sdio transfer for each packet in the bundle, we
> read all packets in one sdio transfer.
>
> This results in significant performance improvement on some targets.
Do you have any numbers? Before and after would be nice to know.
> +static int ath10k_sdio_mbox_rx_fetch(struct ath10k *ar)
> {
> struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_data *pkt = &ar_sdio->rx_pkts[0];
> struct sk_buff *skb = pkt->skb;
> int ret;
>
> - ret = ath10k_sdio_readsb(ar, ar_sdio->mbox_info.htc_addr,
> - skb->data, pkt->alloc_len);
> - pkt->status = ret;
> - if (!ret)
> + ret = ath10k_sdio_read(ar, ar_sdio->mbox_info.htc_addr,
> + skb->data, pkt->alloc_len);
> + if (ret) {
> + ar_sdio->n_rx_pkts = 0;
> + ath10k_sdio_mbox_free_rx_pkt(pkt);
> + } else {
> + pkt->status = ret;
> skb_put(skb, pkt->act_len);
> + }
With this you can avoid the else branch:
if (ret) {
ar_sdio->n_rx_pkts = 0;
ath10k_sdio_mbox_free_rx_pkt(pkt);
return ret;
}
> -static int ath10k_sdio_mbox_rx_fetch(struct ath10k *ar)
> +static int ath10k_sdio_mbox_rx_fetch_bundle(struct ath10k *ar)
> {
> struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_data *pkt;
> int ret, i;
> + u32 pkt_offset = 0, pkt_bundle_len = 0;
> +
> + for (i = 0; i < ar_sdio->n_rx_pkts; i++)
> + pkt_bundle_len += ar_sdio->rx_pkts[i].alloc_len;
> +
> + if (pkt_bundle_len > ATH10K_SDIO_READ_BUF_SIZE) {
> + ret = -ENOMEM;
> + ath10k_err(ar, "bundle size (%d) exceeding limit %d\n",
> + pkt_bundle_len, ATH10K_SDIO_READ_BUF_SIZE);
As this is a recoverable case please use ath10k_warn(). And would
-ENOSPC be more descriptive error?
> + goto err;
> + }
> +
> + ret = ath10k_sdio_readsb(ar, ar_sdio->mbox_info.htc_addr,
> + ar_sdio->sdio_read_buf, pkt_bundle_len);
> + if (ret)
> + goto err;
>
> for (i = 0; i < ar_sdio->n_rx_pkts; i++) {
> - ret = ath10k_sdio_mbox_rx_packet(ar,
> - &ar_sdio->rx_pkts[i]);
> - if (ret)
> - goto err;
> + struct sk_buff *skb = ar_sdio->rx_pkts[i].skb;
> +
> + pkt = &ar_sdio->rx_pkts[i];
> + memcpy(skb->data, ar_sdio->sdio_read_buf + pkt_offset,
> + pkt->alloc_len);
> + pkt->status = 0;
> + skb_put(skb, pkt->act_len);
Shouldn't you call first skb_put() and then memcpy()?
--
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kvalo@codeaurora.org>
To: Erik Stromdahl <erik.stromdahl@gmail.com>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
Alagu Sankar <alagusankar@silex-india.com>
Subject: Re: [PATCH 3/6] ath10k: sdio: read RX packets in bundles
Date: Fri, 12 Apr 2019 16:08:37 +0300 [thread overview]
Message-ID: <874l73e5gq.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20190409190851.4557-4-erik.stromdahl@gmail.com> (Erik Stromdahl's message of "Tue, 9 Apr 2019 21:08:48 +0200")
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> From: Alagu Sankar <alagusankar@silex-india.com>
>
> The existing implementation of initiating multiple sdio transfers for
> receive bundling is slowing down the receive speed.
>
> Instead of having one sdio transfer for each packet in the bundle, we
> read all packets in one sdio transfer.
>
> This results in significant performance improvement on some targets.
Do you have any numbers? Before and after would be nice to know.
> +static int ath10k_sdio_mbox_rx_fetch(struct ath10k *ar)
> {
> struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_data *pkt = &ar_sdio->rx_pkts[0];
> struct sk_buff *skb = pkt->skb;
> int ret;
>
> - ret = ath10k_sdio_readsb(ar, ar_sdio->mbox_info.htc_addr,
> - skb->data, pkt->alloc_len);
> - pkt->status = ret;
> - if (!ret)
> + ret = ath10k_sdio_read(ar, ar_sdio->mbox_info.htc_addr,
> + skb->data, pkt->alloc_len);
> + if (ret) {
> + ar_sdio->n_rx_pkts = 0;
> + ath10k_sdio_mbox_free_rx_pkt(pkt);
> + } else {
> + pkt->status = ret;
> skb_put(skb, pkt->act_len);
> + }
With this you can avoid the else branch:
if (ret) {
ar_sdio->n_rx_pkts = 0;
ath10k_sdio_mbox_free_rx_pkt(pkt);
return ret;
}
> -static int ath10k_sdio_mbox_rx_fetch(struct ath10k *ar)
> +static int ath10k_sdio_mbox_rx_fetch_bundle(struct ath10k *ar)
> {
> struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar);
> + struct ath10k_sdio_rx_data *pkt;
> int ret, i;
> + u32 pkt_offset = 0, pkt_bundle_len = 0;
> +
> + for (i = 0; i < ar_sdio->n_rx_pkts; i++)
> + pkt_bundle_len += ar_sdio->rx_pkts[i].alloc_len;
> +
> + if (pkt_bundle_len > ATH10K_SDIO_READ_BUF_SIZE) {
> + ret = -ENOMEM;
> + ath10k_err(ar, "bundle size (%d) exceeding limit %d\n",
> + pkt_bundle_len, ATH10K_SDIO_READ_BUF_SIZE);
As this is a recoverable case please use ath10k_warn(). And would
-ENOSPC be more descriptive error?
> + goto err;
> + }
> +
> + ret = ath10k_sdio_readsb(ar, ar_sdio->mbox_info.htc_addr,
> + ar_sdio->sdio_read_buf, pkt_bundle_len);
> + if (ret)
> + goto err;
>
> for (i = 0; i < ar_sdio->n_rx_pkts; i++) {
> - ret = ath10k_sdio_mbox_rx_packet(ar,
> - &ar_sdio->rx_pkts[i]);
> - if (ret)
> - goto err;
> + struct sk_buff *skb = ar_sdio->rx_pkts[i].skb;
> +
> + pkt = &ar_sdio->rx_pkts[i];
> + memcpy(skb->data, ar_sdio->sdio_read_buf + pkt_offset,
> + pkt->alloc_len);
> + pkt->status = 0;
> + skb_put(skb, pkt->act_len);
Shouldn't you call first skb_put() and then memcpy()?
--
Kalle Valo
next prev parent reply other threads:[~2019-04-12 13:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 19:08 [PATCH 0/6] ath10k: SDIO and high latency patches from Silex Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 1/6] ath10k: use clean packet headers Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 12:54 ` Kalle Valo
2019-04-12 12:54 ` Kalle Valo
2019-04-09 19:08 ` [PATCH 2/6] ath10k: high latency fixes for beacon buffer Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 3/6] ath10k: sdio: read RX packets in bundles Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 13:08 ` Kalle Valo [this message]
2019-04-12 13:08 ` Kalle Valo
2019-04-09 19:08 ` [PATCH 4/6] ath10k: sdio: add MSDU ID allocation in HTT TX path Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 5/6] ath10k: sdio: add missing error check Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-09 19:08 ` [PATCH 6/6] ath10k: sdio: replace skb_trim with explicit set of skb->len Erik Stromdahl
2019-04-09 19:08 ` Erik Stromdahl
2019-04-12 13:17 ` Kalle Valo
2019-04-12 13:17 ` Kalle Valo
2019-04-15 15:11 ` Erik Stromdahl
2019-04-15 15:11 ` Erik Stromdahl
2019-10-01 12:21 ` Kalle Valo
2019-10-01 12:21 ` Kalle Valo
2019-10-01 12:49 ` Johannes Berg
2019-10-01 12:49 ` Johannes Berg
2019-04-12 12:36 ` [PATCH 0/6] ath10k: SDIO and high latency patches from Silex Kalle Valo
2019-04-12 12:36 ` Kalle Valo
2019-04-14 16:53 ` Erik Stromdahl
2019-04-14 16:53 ` Erik Stromdahl
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=874l73e5gq.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=alagusankar@silex-india.com \
--cc=ath10k@lists.infradead.org \
--cc=erik.stromdahl@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/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.