| Message ID | 1451984419-5727-1-git-send-email-janusz.dziedzic@tieto.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Johannes Berg |
| Headers | show |
On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote: > Add use_minrate param to ieee80211_tx_prepare_skb() function. > This is useful in case we would like to send frames > with lowest rates, eg. nullfunc, probe_resp. I could kind of understand this for short frames like Data nullfunc and PS-Poll, but why would we like to hard code Probe Response frames to be sent at the lowest rate? Shouldn't the frames be sent at a rate that is most likely to get them through and do so in a manner that does not use excessive amount of air time?
On 5 January 2016 at 10:45, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote: >> Add use_minrate param to ieee80211_tx_prepare_skb() function. >> This is useful in case we would like to send frames >> with lowest rates, eg. nullfunc, probe_resp. > > I could kind of understand this for short frames like Data nullfunc and > PS-Poll, but why would we like to hard code Probe Response frames to be > sent at the lowest rate? Shouldn't the frames be sent at a rate that is > most likely to get them through and do so in a manner that does not use > excessive amount of air time? > This is used to get/send probe_req() frame, next used by ath9k "hw_scan" when chanctx used. > -- > Jouni Malinen PGP id EFC895FA -- 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 Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote: > On 5 January 2016 at 10:45, Jouni Malinen <j@w1.fi> wrote: > > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote: > >> Add use_minrate param to ieee80211_tx_prepare_skb() function. > >> This is useful in case we would like to send frames > >> with lowest rates, eg. nullfunc, probe_resp. > > > > I could kind of understand this for short frames like Data nullfunc and > > PS-Poll, but why would we like to hard code Probe Response frames to be > > sent at the lowest rate? Shouldn't the frames be sent at a rate that is > > most likely to get them through and do so in a manner that does not use > > excessive amount of air time? > > > This is used to get/send probe_req() frame, next used by ath9k > "hw_scan" when chanctx used. Sure, but that's not what I'm asking. I'm asking why would we want to force Probe Response frames to use the lowest rate based on that commit message above. If that's a typo and should have been Probe Request frame, I'm going to ask the same question about Probe Request frames. Why would we like to force the lowest rate to be used for them?
On 5 January 2016 at 11:06, Jouni Malinen <j@w1.fi> wrote: > On Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote: >> On 5 January 2016 at 10:45, Jouni Malinen <j@w1.fi> wrote: >> > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote: >> >> Add use_minrate param to ieee80211_tx_prepare_skb() function. >> >> This is useful in case we would like to send frames >> >> with lowest rates, eg. nullfunc, probe_resp. >> > >> > I could kind of understand this for short frames like Data nullfunc and >> > PS-Poll, but why would we like to hard code Probe Response frames to be >> > sent at the lowest rate? Shouldn't the frames be sent at a rate that is >> > most likely to get them through and do so in a manner that does not use >> > excessive amount of air time? >> > >> This is used to get/send probe_req() frame, next used by ath9k >> "hw_scan" when chanctx used. > > Sure, but that's not what I'm asking. I'm asking why would we want to > force Probe Response frames to use the lowest rate based on that commit > message above. If that's a typo and should have been Probe Request > frame, I'm going to ask the same question about Probe Request frames. > Why would we like to force the lowest rate to be used for them? > I did it because most of devices I saw send probe_req using lowest rates? Anyway I can skip this for probe_res() frames in next patch if this is better idea. > -- > Jouni Malinen PGP id EFC895FA -- 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 5 January 2016 at 11:16, Janusz Dziedzic <janusz.dziedzic@tieto.com> wrote: > On 5 January 2016 at 11:06, Jouni Malinen <j@w1.fi> wrote: >> On Tue, Jan 05, 2016 at 10:56:18AM +0100, Janusz Dziedzic wrote: >>> On 5 January 2016 at 10:45, Jouni Malinen <j@w1.fi> wrote: >>> > On Tue, Jan 05, 2016 at 10:00:19AM +0100, Janusz Dziedzic wrote: >>> >> Add use_minrate param to ieee80211_tx_prepare_skb() function. >>> >> This is useful in case we would like to send frames >>> >> with lowest rates, eg. nullfunc, probe_resp. >>> > >>> > I could kind of understand this for short frames like Data nullfunc and >>> > PS-Poll, but why would we like to hard code Probe Response frames to be >>> > sent at the lowest rate? Shouldn't the frames be sent at a rate that is >>> > most likely to get them through and do so in a manner that does not use >>> > excessive amount of air time? >>> > >>> This is used to get/send probe_req() frame, next used by ath9k >>> "hw_scan" when chanctx used. >> >> Sure, but that's not what I'm asking. I'm asking why would we want to >> force Probe Response frames to use the lowest rate based on that commit >> message above. If that's a typo and should have been Probe Request >> frame, I'm going to ask the same question about Probe Request frames. >> Why would we like to force the lowest rate to be used for them? >> > I did it because most of devices I saw send probe_req using lowest rates? > Anyway I can skip this for probe_res() frames in next patch if this is > better idea. > BTW, should we export more params except minrate. I see also IEEE80211_TX_CTL_NO_CCK_RATE is used?? So, other implementation I see is to set info->flags |= IEEE80211_TX_CTL_NO_CCK_RATE | IEEE80211_TX_CTL_USE_MINRATE; In the driver and check this in ieee80211_tx_prepare_skb() before memset(0) in ieee80211_tx_prepare() I will send V2. BR Janusz -- 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 Tue, 2016-01-05 at 11:18 +0100, Janusz Dziedzic wrote: > > BTW, should we export more params except minrate. I see also > IEEE80211_TX_CTL_NO_CCK_RATE is used?? That would be required for P2P. 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 Tue, Jan 05, 2016 at 11:16:52AM +0100, Janusz Dziedzic wrote: > I did it because most of devices I saw send probe_req using lowest rates? > Anyway I can skip this for probe_res() frames in next patch if this is > better idea. Taken into account that there is strong desire to move towards the opposite direction, yes, it would be good not to try to force Probe Request frames use the minimal rate. We already force no-CCK policy for P2P use cases and in the not too distant future, we'll probably need to provide means for forcing at least 1 and 2 Mbps rates not being used for any Probe Request frame..
diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c index b81f65c..ccb2d76 100644 --- a/drivers/net/wireless/ath/ath9k/channel.c +++ b/drivers/net/wireless/ath/ath9k/channel.c @@ -1040,7 +1040,7 @@ static void ath_scan_send_probe(struct ath_softc *sc, skb_set_queue_mapping(skb, IEEE80211_AC_VO); - if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, NULL)) + if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, NULL, true)) goto error; txctl.txq = sc->tx.txq_map[IEEE80211_AC_VO]; @@ -1155,7 +1155,8 @@ ath_chanctx_send_vif_ps_frame(struct ath_softc *sc, struct ath_vif *avp, skb->priority = 7; skb_set_queue_mapping(skb, IEEE80211_AC_VO); - if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, band, &sta)) { + if (!ieee80211_tx_prepare_skb(sc->hw, vif, skb, + band, &sta, true)) { dev_kfree_skb_any(skb); return false; } diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 0ea9b51..7269fca 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -5412,12 +5412,14 @@ void ieee80211_report_wowlan_wakeup(struct ieee80211_vif *vif, * @skb: frame to be sent from within the driver * @band: the band to transmit on * @sta: optional pointer to get the station to send the frame to + * @use_minrate: use lowest rate * * Note: must be called under RCU lock */ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, struct ieee80211_vif *vif, struct sk_buff *skb, - int band, struct ieee80211_sta **sta); + int band, struct ieee80211_sta **sta, + bool use_minrate); /** * struct ieee80211_noa_data - holds temporary data for tracking P2P NoA state diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index a512c4b..ebe8268 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1526,7 +1526,8 @@ static int invoke_tx_handlers(struct ieee80211_tx_data *tx) bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, struct ieee80211_vif *vif, struct sk_buff *skb, - int band, struct ieee80211_sta **sta) + int band, struct ieee80211_sta **sta, + bool use_minrate) { struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif); struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); @@ -1540,6 +1541,9 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw, info->control.vif = vif; info->hw_queue = vif->hw_queue[skb_get_queue_mapping(skb)]; + if (use_minrate) + info->flags |= IEEE80211_TX_CTL_USE_MINRATE; + if (invoke_tx_handlers(&tx)) return false;
Add use_minrate param to ieee80211_tx_prepare_skb() function. This is useful in case we would like to send frames with lowest rates, eg. nullfunc, probe_resp. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> --- drivers/net/wireless/ath/ath9k/channel.c | 5 +++-- include/net/mac80211.h | 4 +++- net/mac80211/tx.c | 6 +++++- 3 files changed, 11 insertions(+), 4 deletions(-)