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

2016-02-08 Thread Emmanuel Grumbach
On Mon, Feb 8, 2016 at 12:00 PM, Michal Kazior wrote: > On 5 February 2016 at 17:47, Dave Taht wrote: >>> A bursted txop can be as big as 5-10ms. If you consider you want to >>> queue 5-10ms worth of data for *each* station at any given time you >>>

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

2016-02-08 Thread Emmanuel Grumbach
On Fri, Feb 5, 2016 at 10:44 AM, Michal Kazior wrote: > On 4 February 2016 at 22:14, Ben Greear wrote: >> 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

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

2016-02-08 Thread Michal Kazior
On 5 February 2016 at 17:47, Dave Taht wrote: >> A bursted txop can be as big as 5-10ms. If you consider you want to >> queue 5-10ms worth of data for *each* station at any given time you >> obviously introduce a lot of lag. If you have 10 stations you might >> end up with

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

2016-02-05 Thread Dave Taht
> A bursted txop can be as big as 5-10ms. If you consider you want to > queue 5-10ms worth of data for *each* station at any given time you > obviously introduce a lot of lag. If you have 10 stations you might > end up with service period at 10*10ms = 100ms. This gets even worse if > you consider

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

2016-02-05 Thread Ben Greear
On 02/05/2016 12:44 AM, Michal Kazior wrote: Per-station queues sound tricky if you consider bufferbloat. To maximize use of airtime (i.e. txop) you need to send big aggregates. Since aggregates are per station-tid to maximize multi-station performance (in AP mode) you'll need to queue a lot

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

2016-02-05 Thread Michal Kazior
On 4 February 2016 at 22:14, Ben Greear wrote: > 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

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

2016-02-04 Thread Ben Greear
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

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

2016-02-04 Thread Emmanuel Grumbach
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

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

2016-02-04 Thread Ben Greear
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

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

2016-02-04 Thread Grumbach, Emmanuel
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