Re: [PATCH] {nl,cfg,mac}80211: Enable control quality monitoring for mesh

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2012-02-24 at 08:40 -0800, Javier Cardona wrote:
> Hi Johannes,
> 
> On Thu, Feb 23, 2012 at 11:19 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-02-23 at 18:30 -0800, Ashok Nagarajan wrote:
> >
> >> +/*
> >> + * NOTE: Mesh peer links are established only if average rssi of the peer
> >> + * candidate satisfies the threshold. sta_meets_rssi_treshold doesn't use
> >> + * hysteresis as fluctuations around threshold have no adverse effects.
> >> + */
> >> +
> >> +#define sta_meets_rssi_threshold(sta, sdata) \
> >> +             (sdata->vif.bss_conf.cqm_rssi_thold == 0 || \
> >> +             ((s8) -ewma_read(&sta->avg_signal)) > \
> >> +              sdata->vif.bss_conf.cqm_rssi_thold)
> >
> > This also isn't right, you're using a value (bss_conf.cqm_rssi_thold)
> > intended for *signalling* for actual *decision making*.
> 
> Isn't that value used for making the decision (in userspace) on
> whether a signal is good enough to associate?

I don't think so, and if it happens to be the same value, that's still
not encoded in the API -- this value is really meant to be only for the
signalling in the API.

> On an open mesh this
> decision takes place in the kernel.  It made more sense to us to reuse
> that parameter for mesh than to introduce a new one.  Would you rather
> see a separate mesh parameter for this?

Yes, I think that makes more sense.

johannes