netdev - Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B3BF25.8080509@candelatech.com>
Date:	Thu, 4 Feb 2016 13:14:13 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Dave Taht <dave.taht@...il.com>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [RFC v2] iwlwifi: pcie: transmit queue auto-sizing

On 02/04/2016 12:56 PM, Grumbach, Emmanuel wrote:
>
>
> On 02/04/2016 10:46 PM, Ben Greear wrote:
>> On 02/04/2016 12:16 PM, Emmanuel Grumbach wrote:
>>> As many (all?) WiFi devices, Intel WiFi devices have
>>> transmit queues which have 256 transmit descriptors
>>> each and each descriptor corresponds to an MPDU.
>>> This means that when it is full, the queue contains
>>> 256 * ~1500 bytes to be transmitted (if we don't have
>>> A-MSDUs). The purpose of those queues is to have enough
>>> packets to be ready for transmission so that when the device
>>> gets an opportunity to transmit (TxOP), it can take as many
>>> packets as the spec allows and aggregate them into one
>>> A-MPDU or even several A-MPDUs if we are using bursts.
>> I guess this is only really usable if you have exactly one
>> peer connected (ie, in station mode)?
>>
>> Otherwise, you could have one slow peer and one fast one,
>> and then I suspect this would not work so well?
>
> Yes. I guess this one (big) limitation. I guess that what would happen
> in this case is that the the latency would constantly jitter. But I also
> noticed that I could reduce the transmit queue to 130 descriptors
> (instead of 256) and still reach maximal throughput because we can
> refill the queues quickly enough.
> In iwlwifi, we have plans to have one queue for each peer.
> This is under development. Not sure when it'll be ready. It also requires
> firmware change obviously.

Per-peer queues will probably be nice, especially if we can keep the
buffer bloat manageable.

>> For reference, ath10k has around 1400 tx descriptors, though
>> in practice not all are usable, and in stock firmware, I'm guessing
>> the NIC will never be able to actually fill up it's tx descriptors
>> and stop traffic.  Instead, it just allows the stack to try to
>> TX, then drops the frame...
>
> 1400 descriptors, ok... but they are not organised in queues?
> (forgive my ignorance of athX drivers)

I think all the details are in the firmware, at least for now.

The firmware details are probably not something I should go into, but suffice it to say
its complex and varies between firmware versions in non-trivial ways.

Thanks,
Ben

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