Can we increase IEEE80211_MAX_QUEUES

Can we increase IEEE80211_MAX_QUEUES

[Ben Greear]

ath10k wants to use vdev-id as a queue-id, and I want to support up to
64 vdevs.  In the 4.2 kernel, this is causing splats when using lots of
vdevs because then queue is out of range.

Can we just increase IEEE80211_MAX_QUEUES to 64?

Thanks,
Ben

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

Re: Can we increase IEEE80211_MAX_QUEUES

[Johannes Berg]

On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote:
> ath10k wants to use vdev-id as a queue-id, and I want to support up
> to
> 64 vdevs.  In the 4.2 kernel, this is causing splats when using lots
> of
> vdevs because then queue is out of range.
> 
> Can we just increase IEEE80211_MAX_QUEUES to 64?
> 

I think not, that would likely cause a lot of data structures to grow
too much. We'd have to do more dynamic things in that case, I suppose.

Does the original premise even make sense though? A single queue for
each vdev seems a bit strange.

johannes

Re: Can we increase IEEE80211_MAX_QUEUES

[Johannes Berg]

On Thu, 2015-12-03 at 21:21 +0100, Johannes Berg wrote:
> 
> Does the original premise even make sense though? A single queue for
> each vdev seems a bit strange.
> 

Btw, it might make more sense to use Felix's txq scheduling thing for
this, where you get a txq for each station. You can still combine them
back any way you want in the driver.

johannes

Re: Can we increase IEEE80211_MAX_QUEUES

[Ben Greear]

On 12/03/2015 12:21 PM, Johannes Berg wrote:
> On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote:
>> ath10k wants to use vdev-id as a queue-id, and I want to support up
>> to
>> 64 vdevs.  In the 4.2 kernel, this is causing splats when using lots
>> of
>> vdevs because then queue is out of range.
>>
>> Can we just increase IEEE80211_MAX_QUEUES to 64?
>>
>
> I think not, that would likely cause a lot of data structures to grow
> too much. We'd have to do more dynamic things in that case, I suppose.
>
> Does the original premise even make sense though? A single queue for
> each vdev seems a bit strange.

I think it is all fakery in the driver, but I'm not sure how easy it
would be to fix.

I'm not certain why I'm suddenly seeing this, but I just started using 4.2 kernel
again and maybe that is the difference.  I also tweaked firmware recently...

I'll make a stab at allowing 64 queues, and also try to figure out why
I started seeing the problem.

Thanks,
Ben

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

Re: Can we increase IEEE80211_MAX_QUEUES

[Ben Greear]

On 12/03/2015 12:21 PM, Johannes Berg wrote:
> On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote:
>> ath10k wants to use vdev-id as a queue-id, and I want to support up
>> to
>> 64 vdevs.  In the 4.2 kernel, this is causing splats when using lots
>> of
>> vdevs because then queue is out of range.
>>
>> Can we just increase IEEE80211_MAX_QUEUES to 64?
>>
>
> I think not, that would likely cause a lot of data structures to grow
> too much. We'd have to do more dynamic things in that case, I suppose.
>
> Does the original premise even make sense though? A single queue for
> each vdev seems a bit strange.

Comments in ath10k claim that the approach makes per-vif tx locking
much easier and that is why that code was added....

Thanks,
Ben

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

Re: Can we increase IEEE80211_MAX_QUEUES

[Michal Kazior]

On 04/12/2015, Ben Greear <greearb@candelatech.com> wrote:
> On 12/03/2015 12:21 PM, Johannes Berg wrote:
>> On Thu, 2015-12-03 at 12:16 -0800, Ben Greear wrote:
>>> ath10k wants to use vdev-id as a queue-id, and I want to support up
>>> to
>>> 64 vdevs.  In the 4.2 kernel, this is causing splats when using lots
>>> of
>>> vdevs because then queue is out of range.
>>>
>>> Can we just increase IEEE80211_MAX_QUEUES to 64?
>>>
>>
>> I think not, that would likely cause a lot of data structures to grow
>> too much. We'd have to do more dynamic things in that case, I suppose.
>>
>> Does the original premise even make sense though? A single queue for
>> each vdev seems a bit strange.
>
> Comments in ath10k claim that the approach makes per-vif tx locking
> much easier and that is why that code was added....

This was introduced for qca6174 firmware which can do multi-channel
and can hint host driver to stop/wake tx queues associated per vdev.


Michal