| Message ID | 1396211704-4677-3-git-send-email-antonio@meshcoding.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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,