On 2018-05-18 15:00, Johannes Berg wrote:
On Wed, 2018-05-16 at 10:04 +0530, Sriram R wrote:
But, I wanted to avoid,
1. Static indexing and memory allocation based on MCS count((8x3)24
entries for HT and (10x3)30 for VHT within allocated 36 entries) so
that
it's scalable.
Do you expect that the rate control on the other side flips through
MCSes so fast that this little cache will need to be flushed
significantly?
Not really Johannes. Dynamic allocation (with indexing based on encoded
rate)was tried out in this patch
so as to have the rate table independent of MCS Count(so that it works
without changes
when new mcs's is used in HE).
2. Remote chance of dropping a stats(Though it does not have much
impact)
Yeah this doesn't seem like a concern either way. How many packets and
how little time ... :)
Right!
And to allow,
1. A 'station dump' kind of interface to dump the complete collected
stats instead of returning only current snapshot of the stats within
kernel.
This *completely* contradict keeping limits on the kernel memory
consumed, so basically I don't think this is feasible.
Ok,Understood.
Also, do you feel it would be good to have both ,i.e complete stats
collection within kernel(this approach) and dump+clear of stats on
reaching threshold(your approach) and have one of these two modes
selected based on the requirement.
No, honestly, I don't. If an application wants these statistics, then I
feel that we can impose *some* requirements and not leave it at "let me
just enable it and have the kernel do all the work for me".
Right, Thanks for the suggestions. I'll send the next revision based on
your approach
of flushing the rate table(whenever its' requested or when we hit a
limit)
Thanks and Regards,
Sriram.R
johannes
