Can we increase IEEE80211_MAX_QUEUES
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 8 lines · 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_QUEUESto 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
Quoted 4 lines · Johannes Berg
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
Quoted 7 lines · Johannes Berg
Quoted 6 lines · 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.
Quoted 8 lines
Quoted 2 lines
Can we just increase
IEEE80211_MAX_QUEUESto 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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 7 lines · Johannes Berg
Quoted 6 lines · 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.
Quoted 8 lines
Quoted 2 lines
Can we just increase
IEEE80211_MAX_QUEUESto 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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 11 lines · Ben Greear
Quoted 10 lines · Johannes Berg
Quoted 8 lines · 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_QUEUESto 64?
Quoted 8 lines
Quoted 5 lines
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