RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-09-03 Thread Wen Gong
> -Original Message-
> From: ath10k  On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org
> Subject: [EXT] [PATCH 4/7] ath10k: disable TX complete indication of htt for
> sdio
> 
Patch v2 sent, https://patchwork.kernel.org/patch/6685/ 
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-27 Thread Wen Gong


> -Original Message-
> From: ath10k  On Behalf Of Nicolas
> Boichat
> Sent: Tuesday, August 27, 2019 3:56 PM
> To: Wen Gong 
> Cc: open list:NETWORKING DRIVERS (WIRELESS)  wirel...@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of htt
> for sdio
> 
> On Tue, Aug 20, 2019 at 7:55 PM Wen Gong  wrote:
> >
> > Tx complete message from firmware cost bus bandwidth of sdio, and bus
> > bandwidth is the bollteneck of throughput, it will effect the bandwidth
> > occupancy of data packet of TX and RX.
> >
> > This patch disable TX complete indication from firmware for htt data
> > packet, it results in significant performance improvement on TX path.
> >
Patch v2 sent with the changes, https://patchwork.kernel.org/patch/6685/

> >
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


Re: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-27 Thread Nicolas Boichat
On Tue, Aug 20, 2019 at 7:55 PM Wen Gong  wrote:
>
> Tx complete message from firmware cost bus bandwidth of sdio, and bus
> bandwidth is the bollteneck of throughput, it will effect the bandwidth
> occupancy of data packet of TX and RX.
>
> This patch disable TX complete indication from firmware for htt data
> packet, it results in significant performance improvement on TX path.
>
> The downside of this patch is ath10k will not know the TX status of
> the data packet for poor signal situation. Although upper network stack
> or application layer have retry mechanism, the retry will be later than
> ath10k get the TX fail status if not disable TX complete.
>
> This patch only effect sdio chip, it will not effect PCI, SNOC etc.
>
> Tested with QCA6174 SDIO with firmware
> WLAN.RMH.4.4.1-7-QCARMSWP-1.
>
> Signed-off-by: Wen Gong 
> ---
>  drivers/net/wireless/ath/ath10k/core.c   |  6 +
>  drivers/net/wireless/ath/ath10k/hif.h|  9 
>  drivers/net/wireless/ath/ath10k/htc.c| 11 +
>  drivers/net/wireless/ath/ath10k/htc.h|  3 +++
>  drivers/net/wireless/ath/ath10k/htt.c|  5 +
>  drivers/net/wireless/ath/ath10k/htt.h| 13 ++-
>  drivers/net/wireless/ath/ath10k/htt_rx.c | 38 
> +++-
>  drivers/net/wireless/ath/ath10k/htt_tx.c | 30 +
>  drivers/net/wireless/ath/ath10k/hw.h |  2 +-
>  drivers/net/wireless/ath/ath10k/sdio.c   | 28 +++
>  10 files changed, 142 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index dc45d16..762bba0 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -30,6 +30,7 @@
>
>  static unsigned int ath10k_cryptmode_param;
>  static bool uart_print;
> +static bool disable_tx_comp = true;

Instead of a disable_x = true variable, maybe you're better off using
a enable_tx_comp variable, with a default value of 0?

>  static bool skip_otp;
>  static bool rawmode;
>  static bool fw_diag_log;
> @@ -41,6 +42,9 @@
>  module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
>  module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
>  module_param(uart_print, bool, 0644);
> +
> +/* If upper layer need the TX complete status, it can enable tx complete */
> +module_param(disable_tx_comp, bool, 0644);
>  module_param(skip_otp, bool, 0644);
>  module_param(rawmode, bool, 0644);
>  module_param(fw_diag_log, bool, 0644);
> @@ -689,6 +693,8 @@ static void ath10k_init_sdio(struct ath10k *ar, enum 
> ath10k_firmware_mode mode)
>  * is used for SDIO. disable it until fixed
>  */
> param &= ~HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
> +   if (disable_tx_comp)
> +   param |= HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
>
> /* Alternate credit size of 1544 as used by SDIO firmware is
>  * not big enough for mac80211 / native wifi frames. disable it
> diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
> b/drivers/net/wireless/ath/ath10k/hif.h
> index 496ee34..0dd8973 100644
> --- a/drivers/net/wireless/ath/ath10k/hif.h
> +++ b/drivers/net/wireless/ath/ath10k/hif.h
> @@ -56,6 +56,8 @@ struct ath10k_hif_ops {
>
> int (*swap_mailbox)(struct ath10k *ar);
>
> +   int (*get_htt_tx_complete)(struct ath10k *ar);
> +
> int (*map_service_to_pipe)(struct ath10k *ar, u16 service_id,
>u8 *ul_pipe, u8 *dl_pipe);
>
> @@ -144,6 +146,13 @@ static inline int ath10k_hif_swap_mailbox(struct ath10k 
> *ar)
> return 0;
>  }
>
> +static inline int ath10k_hif_get_htt_tx_complete(struct ath10k *ar)
> +{
> +   if (ar->hif.ops->get_htt_tx_complete)
> +   return ar->hif.ops->get_htt_tx_complete(ar);
> +   return 0;
> +}
> +
>  static inline int ath10k_hif_map_service_to_pipe(struct ath10k *ar,
>  u16 service_id,
>  u8 *ul_pipe, u8 *dl_pipe)
> diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
> b/drivers/net/wireless/ath/ath10k/htc.c
> index 1d4d1a1..7357a5a 100644
> --- a/drivers/net/wireless/ath/ath10k/htc.c
> +++ b/drivers/net/wireless/ath/ath10k/htc.c
> @@ -660,6 +660,17 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
> return 0;
>  }
>
> +void ath10k_htc_change_tx_credit_flow(struct ath10k_htc *htc,
> + enum ath10k_htc_ep_id eid,
> + bool enable)
> +{
> +   struct ath10k *ar = htc->ar;
> +   struct ath10k_htc_ep *ep;
> +
> +   ep = >htc.endpoint[eid];

Merge this with the variable declaration.

> +   ep->tx_credit_flow_enabled = enable;
> +}
> +
>  int ath10k_htc_connect_service(struct ath10k_htc *htc,
>struct ath10k_htc_svc_conn_req *conn_req,
>struct ath10k_htc_svc_conn_resp 

RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-23 Thread Toke Høiland-Jørgensen
Wen Gong  writes:

>> -Original Message-
>> From: Toke Høiland-Jørgensen 
>> Sent: Thursday, August 22, 2019 8:12 PM
>> To: Wen Gong ; Wen Gong
>> ; ath10k@lists.infradead.org
>> Cc: linux-wirel...@vger.kernel.org
>> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
>> for sdio
>> >> What's a typical limit in the firmware?
>> > It is 96 data packet in my test. It can changed in firmware code.
>> 
>> Right, I see. Is this counter available in all ath10k firmware, or is it
>> SDIO only?
>> 
> It is only for SDIO.
> For PCIE, it does not have credit limit, firmware memory only need to save
> The tx descriptor, not need for palyload.

OK, too bad. Thanks for the explanations :)

-Toke

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-22 Thread Wen Gong
> -Original Message-
> From: Toke Høiland-Jørgensen 
> Sent: Thursday, August 22, 2019 8:12 PM
> To: Wen Gong ; Wen Gong
> ; ath10k@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org
> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
> for sdio
> >> What's a typical limit in the firmware?
> > It is 96 data packet in my test. It can changed in firmware code.
> 
> Right, I see. Is this counter available in all ath10k firmware, or is it
> SDIO only?
> 
It is only for SDIO.
For PCIE, it does not have credit limit, firmware memory only need to save
The tx descriptor, not need for palyload.
> I'm asking because this could also be a way of implementing something
> like Byte Queue Limits (though I'm not sure how effective it would be).
> 
> -Toke


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-22 Thread Toke Høiland-Jørgensen
Wen Gong  writes:

>> -Original Message-
>> From: Toke Høiland-Jørgensen 
>> Sent: Wednesday, August 21, 2019 6:10 PM
>> To: Wen Gong ; Wen Gong
>> ; ath10k@lists.infradead.org
>> Cc: linux-wirel...@vger.kernel.org
>> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
>> for sdio
>> 
>> Wen Gong  writes:
>> 
>> >> -Original Message-
>> >> From: ath10k  On Behalf Of Toke
>> >> Høiland-Jørgensen
>> >> Sent: Tuesday, August 20, 2019 8:24 PM
>> >> To: Wen Gong ; ath10k@lists.infradead.org
>> >> Cc: linux-wirel...@vger.kernel.org
>> >> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of
>> htt
>> > When this patch applied, firmware will not indicate tx complete for tx
>> > Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
>> > This htt msg will tell how many data tx complete without status(status
>> maybe success/fail).
>> 
>> Ah, so this is basically a counter of how much data is currently queued
>> in the firmware?
> Yes.
>> 
>> >> And could you explain what the credits thing is for, please? :)
>> > For high latency bus chip, all the tx data's content(include ip/udp/tcp
>> header
>> > and payload) will be transfer to firmware's memory via bus.
>> > And firmware has limited memory for tx data, the tx data's content must
>> > Saved in firmware memory before it tx complete, if ath10k transfer tx
>> > data more than the limit, firmware will occur error. The credit is used
>> > to avoid ath10k exceed the limit.
>> 
>> What's a typical limit in the firmware?
> It is 96 data packet in my test. It can changed in firmware code.

Right, I see. Is this counter available in all ath10k firmware, or is it
SDIO only?

I'm asking because this could also be a way of implementing something
like Byte Queue Limits (though I'm not sure how effective it would be).

-Toke


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-21 Thread Wen Gong
> -Original Message-
> From: Toke Høiland-Jørgensen 
> Sent: Wednesday, August 21, 2019 6:10 PM
> To: Wen Gong ; Wen Gong
> ; ath10k@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org
> Subject: [EXT] RE: [PATCH 4/7] ath10k: disable TX complete indication of htt
> for sdio
> 
> Wen Gong  writes:
> 
> >> -Original Message-
> >> From: ath10k  On Behalf Of Toke
> >> Høiland-Jørgensen
> >> Sent: Tuesday, August 20, 2019 8:24 PM
> >> To: Wen Gong ; ath10k@lists.infradead.org
> >> Cc: linux-wirel...@vger.kernel.org
> >> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of
> htt
> > When this patch applied, firmware will not indicate tx complete for tx
> > Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
> > This htt msg will tell how many data tx complete without status(status
> maybe success/fail).
> 
> Ah, so this is basically a counter of how much data is currently queued
> in the firmware?
Yes.
> 
> >> And could you explain what the credits thing is for, please? :)
> > For high latency bus chip, all the tx data's content(include ip/udp/tcp
> header
> > and payload) will be transfer to firmware's memory via bus.
> > And firmware has limited memory for tx data, the tx data's content must
> > Saved in firmware memory before it tx complete, if ath10k transfer tx
> > data more than the limit, firmware will occur error. The credit is used
> > to avoid ath10k exceed the limit.
> 
> What's a typical limit in the firmware?
It is 96 data packet in my test. It can changed in firmware code.
> 
> -Toke


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-21 Thread Toke Høiland-Jørgensen
Wen Gong  writes:

>> -Original Message-
>> From: ath10k  On Behalf Of Toke
>> Høiland-Jørgensen
>> Sent: Tuesday, August 20, 2019 8:24 PM
>> To: Wen Gong ; ath10k@lists.infradead.org
>> Cc: linux-wirel...@vger.kernel.org
>> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of htt
>> for sdio
>> 
>> Wen Gong  writes:
>> 
>> > Tx complete message from firmware cost bus bandwidth of sdio, and bus
>> > bandwidth is the bollteneck of throughput, it will effect the bandwidth
>> > occupancy of data packet of TX and RX.
>> >
>> > This patch disable TX complete indication from firmware for htt data
>> > packet, it results in significant performance improvement on TX path.
>> 
>> Wait, how does that work? Am I understanding it correctly that this
>> replaces a per-packet TX completion with a periodic one sent out of
>> band?
> When this patch applied, firmware will not indicate tx complete for tx
> Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
> This htt msg will tell how many data tx complete without status(status maybe 
> success/fail).

Ah, so this is basically a counter of how much data is currently queued
in the firmware?

>> And could you explain what the credits thing is for, please? :)
> For high latency bus chip, all the tx data's content(include ip/udp/tcp header
> and payload) will be transfer to firmware's memory via bus.
> And firmware has limited memory for tx data, the tx data's content must
> Saved in firmware memory before it tx complete, if ath10k transfer tx
> data more than the limit, firmware will occur error. The credit is used
> to avoid ath10k exceed the limit.

What's a typical limit in the firmware?

-Toke

___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k


RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-21 Thread Wen Gong
> -Original Message-
> From: ath10k  On Behalf Of Toke
> Høiland-Jørgensen
> Sent: Tuesday, August 20, 2019 8:24 PM
> To: Wen Gong ; ath10k@lists.infradead.org
> Cc: linux-wirel...@vger.kernel.org
> Subject: [EXT] Re: [PATCH 4/7] ath10k: disable TX complete indication of htt
> for sdio
> 
> Wen Gong  writes:
> 
> > Tx complete message from firmware cost bus bandwidth of sdio, and bus
> > bandwidth is the bollteneck of throughput, it will effect the bandwidth
> > occupancy of data packet of TX and RX.
> >
> > This patch disable TX complete indication from firmware for htt data
> > packet, it results in significant performance improvement on TX path.
> 
> Wait, how does that work? Am I understanding it correctly that this
> replaces a per-packet TX completion with a periodic one sent out of
> band?
When this patch applied, firmware will not indicate tx complete for tx
Data, it only indicate HTT_T2H_MSG_TYPE_TX_CREDIT_UPDATE_IND,
This htt msg will tell how many data tx complete without status(status maybe 
success/fail).
> 
> And could you explain what the credits thing is for, please? :)
For high latency bus chip, all the tx data's content(include ip/udp/tcp header
and payload) will be transfer to firmware's memory via bus.
And firmware has limited memory for tx data, the tx data's content must
Saved in firmware memory before it tx complete, if ath10k transfer tx
data more than the limit, firmware will occur error. The credit is used
to avoid ath10k exceed the limit.
> 
> -Toke
> 
> ___
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k


Re: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-20 Thread Toke Høiland-Jørgensen
Wen Gong  writes:

> Tx complete message from firmware cost bus bandwidth of sdio, and bus
> bandwidth is the bollteneck of throughput, it will effect the bandwidth
> occupancy of data packet of TX and RX.
>
> This patch disable TX complete indication from firmware for htt data
> packet, it results in significant performance improvement on TX path.

Wait, how does that work? Am I understanding it correctly that this
replaces a per-packet TX completion with a periodic one sent out of
band?

And could you explain what the credits thing is for, please? :)

-Toke


[PATCH 4/7] ath10k: disable TX complete indication of htt for sdio

2019-08-20 Thread Wen Gong
Tx complete message from firmware cost bus bandwidth of sdio, and bus
bandwidth is the bollteneck of throughput, it will effect the bandwidth
occupancy of data packet of TX and RX.

This patch disable TX complete indication from firmware for htt data
packet, it results in significant performance improvement on TX path.

The downside of this patch is ath10k will not know the TX status of
the data packet for poor signal situation. Although upper network stack
or application layer have retry mechanism, the retry will be later than
ath10k get the TX fail status if not disable TX complete.

This patch only effect sdio chip, it will not effect PCI, SNOC etc.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-7-QCARMSWP-1.

Signed-off-by: Wen Gong 
---
 drivers/net/wireless/ath/ath10k/core.c   |  6 +
 drivers/net/wireless/ath/ath10k/hif.h|  9 
 drivers/net/wireless/ath/ath10k/htc.c| 11 +
 drivers/net/wireless/ath/ath10k/htc.h|  3 +++
 drivers/net/wireless/ath/ath10k/htt.c|  5 +
 drivers/net/wireless/ath/ath10k/htt.h| 13 ++-
 drivers/net/wireless/ath/ath10k/htt_rx.c | 38 +++-
 drivers/net/wireless/ath/ath10k/htt_tx.c | 30 +
 drivers/net/wireless/ath/ath10k/hw.h |  2 +-
 drivers/net/wireless/ath/ath10k/sdio.c   | 28 +++
 10 files changed, 142 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index dc45d16..762bba0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -30,6 +30,7 @@
 
 static unsigned int ath10k_cryptmode_param;
 static bool uart_print;
+static bool disable_tx_comp = true;
 static bool skip_otp;
 static bool rawmode;
 static bool fw_diag_log;
@@ -41,6 +42,9 @@
 module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
 module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
 module_param(uart_print, bool, 0644);
+
+/* If upper layer need the TX complete status, it can enable tx complete */
+module_param(disable_tx_comp, bool, 0644);
 module_param(skip_otp, bool, 0644);
 module_param(rawmode, bool, 0644);
 module_param(fw_diag_log, bool, 0644);
@@ -689,6 +693,8 @@ static void ath10k_init_sdio(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
 * is used for SDIO. disable it until fixed
 */
param &= ~HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
+   if (disable_tx_comp)
+   param |= HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
 
/* Alternate credit size of 1544 as used by SDIO firmware is
 * not big enough for mac80211 / native wifi frames. disable it
diff --git a/drivers/net/wireless/ath/ath10k/hif.h 
b/drivers/net/wireless/ath/ath10k/hif.h
index 496ee34..0dd8973 100644
--- a/drivers/net/wireless/ath/ath10k/hif.h
+++ b/drivers/net/wireless/ath/ath10k/hif.h
@@ -56,6 +56,8 @@ struct ath10k_hif_ops {
 
int (*swap_mailbox)(struct ath10k *ar);
 
+   int (*get_htt_tx_complete)(struct ath10k *ar);
+
int (*map_service_to_pipe)(struct ath10k *ar, u16 service_id,
   u8 *ul_pipe, u8 *dl_pipe);
 
@@ -144,6 +146,13 @@ static inline int ath10k_hif_swap_mailbox(struct ath10k 
*ar)
return 0;
 }
 
+static inline int ath10k_hif_get_htt_tx_complete(struct ath10k *ar)
+{
+   if (ar->hif.ops->get_htt_tx_complete)
+   return ar->hif.ops->get_htt_tx_complete(ar);
+   return 0;
+}
+
 static inline int ath10k_hif_map_service_to_pipe(struct ath10k *ar,
 u16 service_id,
 u8 *ul_pipe, u8 *dl_pipe)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
b/drivers/net/wireless/ath/ath10k/htc.c
index 1d4d1a1..7357a5a 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -660,6 +660,17 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
return 0;
 }
 
+void ath10k_htc_change_tx_credit_flow(struct ath10k_htc *htc,
+ enum ath10k_htc_ep_id eid,
+ bool enable)
+{
+   struct ath10k *ar = htc->ar;
+   struct ath10k_htc_ep *ep;
+
+   ep = >htc.endpoint[eid];
+   ep->tx_credit_flow_enabled = enable;
+}
+
 int ath10k_htc_connect_service(struct ath10k_htc *htc,
   struct ath10k_htc_svc_conn_req *conn_req,
   struct ath10k_htc_svc_conn_resp *conn_resp)
diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index 8c79b9e..78bc3ae 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -367,6 +367,9 @@ struct ath10k_htc {
 int ath10k_htc_connect_service(struct ath10k_htc *htc,
   struct ath10k_htc_svc_conn_req  *conn_req,
   struct