On Wed, May 23, 2018 at 06:25:49PM +0200, Erik Stromdahl wrote:
>
>
> On 05/22/2018 11:15 PM, Niklas Cassel wrote:
>
>
> > >
> > > Earlier we observed performance issues in calling push_pending from each
> > > tx completion. IMHO this change may introduce the same problem again.
> >
> > I pre
On 2018-05-23 09:25, Erik Stromdahl wrote:
On 05/22/2018 11:15 PM, Niklas Cassel wrote:
[...]
Perhaps it would be possible to call ath10k_mac_tx_push_pending()
from the equivalent to ath10k_htt_txrx_compl_task(),
but from SDIO's point of view.
An equivalent for SDIO would most likely be
*ath
On 05/22/2018 11:15 PM, Niklas Cassel wrote:
Earlier we observed performance issues in calling push_pending from each
tx completion. IMHO this change may introduce the same problem again.
I prefer functional TX over performance issues,
but I agree that it is unfortunate that SDIO doesn't u
On 2018-05-22 14:15, Niklas Cassel wrote:
On Mon, May 21, 2018 at 04:11:38PM -0700, Rajkumar Manoharan wrote:
On 2018-05-21 13:43, Niklas Cassel wrote:
> The following problem was observed when running iperf:
[...]
Sorry for the late response. ath10k_mac_tx_push_pending is already
called
at
On Mon, May 21, 2018 at 04:11:38PM -0700, Rajkumar Manoharan wrote:
> On 2018-05-21 13:43, Niklas Cassel wrote:
> > The following problem was observed when running iperf:
> [...]
> >
> > In order to avoid trying to flush the queue every time we free a frame,
> > only do this when there are 3 or le
On 2018-05-21 13:43, Niklas Cassel wrote:
The following problem was observed when running iperf:
[...]
In order to avoid trying to flush the queue every time we free a frame,
only do this when there are 3 or less frames pending, and while we
actually have frames in the queue. This logic was co
The following problem was observed when running iperf:
[ 3] 0.0- 1.0 sec 2.00 MBytes 16.8 Mbits/sec
[ 3] 1.0- 2.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 3] 2.0- 3.0 sec 3.25 MBytes 27.3 Mbits/sec
[ 3] 3.0- 4.0 sec 655 KBytes 5.36 Mbits/sec
[ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec
