On 2018-08-28 14:30, Johannes Berg wrote:
Hi,
Sorry for the late reply, my work hours are limited right now.
I wanted to give a try with rhashtable and get your thoughts, since it
gave below flexibility to original patch,
1. avoids creating static memory when userspace starts accumulating
stat
Hi,
Sorry for the late reply, my work hours are limited right now.
> I wanted to give a try with rhashtable and get your thoughts, since it
> gave below flexibility to original patch,
> 1. avoids creating static memory when userspace starts accumulating
> stats. 36 rate entries were used in ori
On 2018-06-15 17:55, Johannes Berg wrote:
Why did you change to rhashtable?
Hi Johannes,
I wanted to give a try with rhashtable and get your thoughts, since it
gave below flexibility to original patch,
1. avoids creating static memory when userspace starts accumulating
stats. 36 rate entries w
Why did you change to rhashtable?
That seems very strange, since we explicitly want to limit the number of
entries, but rhashtable will grow/shrink as required.
I think I liked my approach better since it allowed us to clearly limit
the memory consumption for this.
johannes
This patch adds support for the mac80211 to collect rx statistics
(Packet count and total bytes received) per-rate, per-station when
subscribed by user space clients.
Note that the rate field passed on to the userspace from mac80211
is an encoded value where different rate attributes such as
type(
