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? > 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 ... :) > 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. > 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". johannes
