Re: [PATCH 1/3] cfg80211: add get_max_tp() API

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2013-04-11 at 11:56 +0200, Johannes Berg wrote:
> On Tue, 2013-04-09 at 13:34 +0200, Antonio Quartulli wrote:
> 
> > > Anyway my concern is that you're adding something that's rather minstrel
> > > specific. It's not really usable by any other algorithm, you're
> > > reporting minstrel's estimation of the throughput. If you report the
> > > current "best" rate, that'll probably get you pretty much the same
> > > behaviour overall, but be more portable to other algorithms I think.
> > 
> > I understand your concern. My guess was that every algorithm was "somehow" able
> > to provide such measurement. The point is that the throughput value is computed
> > so that it also take probability of success into consideration.
> > This means that two nodes using the same rate may have different throughputs
> > (and this is important when building our distributed metric).
> > 
> > However, nothing prevents any algorithm to implement the API the way it can do.
> > I've not looked into other RC implementations yet, but I guess they would have a
> > similar value to return too?
> 
> Maybe, yeah.
> 
> Anyway, I think having a separate externally visible API here is
> overkill. It would seem a lot simpler to return it (to userspace) in the
> station information, and (separately) allow other kernel modules to
> request station information as well.
> 
> Also I'm not sure it should be called "max_tp"? It's more like "expected
> throughput" or something like that?

Hm, no, that's not really it either ... It's maybe more like "current
usable data rate" (as opposed to PHY rate?)

johannes