Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
To:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
From:   Ben Greear <greearb@candelatech.com>
Subject: Does ath10k firmware need to do congestion control?
Organization: Candela Technologies
Message-ID: <20d8f9cf-1b5c-6617-f0a6-4f0083c6d64c@candelatech.com>
Date:   Wed, 8 Jan 2020 09:54:48 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hello,

While debugging some packet drops in the tx path with ath10k-ct wave-2 stuff,
we found that the firmware congestion control was causing packets to be discarded.  The congestion
control tries to reserve a certain number of descriptors for higher priority packets,
so the driver never applies any real back pressure since it will have some tx descriptors
available (though firmware will immediately drop them).

If the upper stacks are already doing QoS/WMM type logic, then there should be little use
of leaving the congestion control compiled into the firmware.

So question is:  What is the state of the upper stack with regard to QoS/WMM congestion
control and throttling?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com