| Message ID | 1396211704-4677-3-git-send-email-antonio@meshcoding.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers |
Return-Path: <antonio@meshcoding.com> Received: from s3.neomailbox.net (s3.neomailbox.net [178.209.62.157]) by open-mesh.org (Postfix) with ESMTPS id 22A7D6009E4 for <b.a.t.m.a.n@lists.open-mesh.org>; Sun, 30 Mar 2014 22:35:36 +0200 (CEST) From: Antonio Quartulli <antonio@meshcoding.com> To: Johannes Berg <johannes@sipsolutions.net> Date: Sun, 30 Mar 2014 22:35:00 +0200 Message-Id: <1396211704-4677-3-git-send-email-antonio@meshcoding.com> In-Reply-To: <1396211704-4677-1-git-send-email-antonio@meshcoding.com> References: <1396211704-4677-1-git-send-email-antonio@meshcoding.com> Cc: devel@lists.open80211s.org, b.a.t.m.a.n@lists.open-mesh.org, linux-wireless@vger.kernel.org, Antonio Quartulli <antonio@open-mesh.com> Subject: [B.A.T.M.A.N.] [RFCv2 2/6] mac80211: add new RC API to retrieve expected throughput X-BeenThere: b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n@lists.open-mesh.org> List-Id: The list for a Better Approach To Mobile Ad-hoc Networking <b.a.t.m.a.n.lists.open-mesh.org> List-Unsubscribe: <https://lists.open-mesh.org/mm/options/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=unsubscribe> List-Archive: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/> List-Post: <mailto:b.a.t.m.a.n@lists.open-mesh.org> List-Help: <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=help> List-Subscribe: <https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n>, <mailto:b.a.t.m.a.n-request@lists.open-mesh.org?subject=subscribe> X-List-Received-Date: Sun, 30 Mar 2014 20:35:37 -0000 |
Commit Message
Antonio Quartulli
March 30, 2014, 8:35 p.m. UTC
From: Antonio Quartulli <antonio@open-mesh.com> In order to make get_station() export the expected throughput, we need a new API which extracts such information from the Rate Control algorithm. Therefore add the get_expected_throughput() member to the rate_control_ops structure. Signed-off-by: Antonio Quartulli <antonio@open-mesh.com> --- include/net/mac80211.h | 3 +++ 1 file changed, 3 insertions(+)
Comments
On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: > From: Antonio Quartulli <antonio@open-mesh.com> > > In order to make get_station() export the expected > throughput, we need a new API which extracts such > information from the Rate Control algorithm. > Therefore add the get_expected_throughput() member > to the rate_control_ops structure. What about drivers with HW rate control? johannes
On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: > + u32 (*get_expected_throughput)(void *priv, void *priv_sta, > + struct ieee80211_supported_band *sband); why would that need an sband argument? johannes
On 08/04/14 12:03, Johannes Berg wrote: > On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: >> From: Antonio Quartulli <antonio@open-mesh.com> >> >> In order to make get_station() export the expected >> throughput, we need a new API which extracts such >> information from the Rate Control algorithm. >> Therefore add the get_expected_throughput() member >> to the rate_control_ops structure. > > What about drivers with HW rate control? > True, they do not implement the rate_control_ops API. Therefore, as discussed on IRC, I need to move this new API at the mac80211 level, so that each driver can implement it the way it prefer. Cheers,
On 08/04/14 12:04, Johannes Berg wrote: > On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: > >> + u32 (*get_expected_throughput)(void *priv, void *priv_sta, >> + struct ieee80211_supported_band *sband); > > why would that need an sband argument? > I needed this because I saw it is required by some RC algo (only minstrel) to extract the bitrate starting from the index. You can check patch 4/6 for this: + bitrate = sband->bitrates[mi->r[idx].rix].bitrate; maybe I can extract it from another structure? I couldn't find any way.. Cheers,
On Thu, 2014-04-10 at 17:46 +0200, Antonio Quartulli wrote: > > What about drivers with HW rate control? > > > > True, they do not implement the rate_control_ops API. > > Therefore, as discussed on IRC, I need to move this new API at the > mac80211 level, so that each driver can implement it the way it prefer. Well, not *move*, but rather have both. Or you can just say that the drivers that may need this can worry about it ... johannes
On Thu, 2014-04-10 at 17:53 +0200, Antonio Quartulli wrote: > > On 08/04/14 12:04, Johannes Berg wrote: > > On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: > > > >> + u32 (*get_expected_throughput)(void *priv, void *priv_sta, > >> + struct ieee80211_supported_band *sband); > > > > why would that need an sband argument? > > > > I needed this because I saw it is required by some RC algo (only > minstrel) to extract the bitrate starting from the index. > > You can check patch 4/6 for this: > > + bitrate = sband->bitrates[mi->r[idx].rix].bitrate; > > maybe I can extract it from another structure? I couldn't find any way.. Bit strange that the algorithm doesn't have the band, if it has an index? but I guess I didn't check all the patches... johannes
On 10/04/14 19:13, Johannes Berg wrote: > On Thu, 2014-04-10 at 17:46 +0200, Antonio Quartulli wrote: > >>> What about drivers with HW rate control? >>> >> >> True, they do not implement the rate_control_ops API. >> >> Therefore, as discussed on IRC, I need to move this new API at the >> mac80211 level, so that each driver can implement it the way it prefer. > > Well, not *move*, but rather have both. Or you can just say that the > drivers that may need this can worry about it ... > You are right, I meant to *add* another API at the mac80211 level and have both. I think this is the cleanest solution. Cheers,
On 10/04/14 19:14, Johannes Berg wrote: > On Thu, 2014-04-10 at 17:53 +0200, Antonio Quartulli wrote: >> >> On 08/04/14 12:04, Johannes Berg wrote: >>> On Sun, 2014-03-30 at 22:35 +0200, Antonio Quartulli wrote: >>> >>>> + u32 (*get_expected_throughput)(void *priv, void *priv_sta, >>>> + struct ieee80211_supported_band *sband); >>> >>> why would that need an sband argument? >>> >> >> I needed this because I saw it is required by some RC algo (only >> minstrel) to extract the bitrate starting from the index. >> >> You can check patch 4/6 for this: >> >> + bitrate = sband->bitrates[mi->r[idx].rix].bitrate; >> >> maybe I can extract it from another structure? I couldn't find any way.. > > Bit strange that the algorithm doesn't have the band, if it has an > index? but I guess I didn't check all the patches... I just rechecked, and it looked to me that all the other functions in Minstreal (non-HT) take the sband as argument. It is not stored anywhere and therefore it has to be passed as argument to this new API as well.. A general beautification might be applied to rate_control_ops (and not only)...but it is out of the scope of this patchset :) Cheers,
diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 604e279..209e004 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -4476,6 +4476,9 @@ struct rate_control_ops { void (*add_sta_debugfs)(void *priv, void *priv_sta, struct dentry *dir); void (*remove_sta_debugfs)(void *priv, void *priv_sta); + + u32 (*get_expected_throughput)(void *priv, void *priv_sta, + struct ieee80211_supported_band *sband); }; static inline int rate_supported(struct ieee80211_sta *sta,