On Thursday 26 November 2015 18:25:26 Johannes Berg wrote: > > We have required the support for rate parsing (legacy + HT) for some > > tests. > > It is already known that this may not be the best place to set this > > flag > > (IEEE80211_TX_CTRL_RATE_INJECT) but the main flags field is already > > full. > > It seems you could perhaps put that into struct > ieee80211_tx_data::flags? Or is it required somewhere outside the > mac80211 processing? The flag itself has to be set when the radiotap information is available+parsed and when the actual rate information calculation should happen. Afaik the ieee80211_tx_data is always a local variable on the stack. Either from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or ieee80211_get_buffered_bc. But the parsing of the radiotap header happens before that in ieee80211_monitor_start_xmit. And after that it calls ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not available when the radiotap header is parsed. > Otherwise I think the place is fine? What issue do you have with it? > > > There is also the problem that powersave could overwrite the rate > > control > > fields - so either we disable powersave queueing or find a different > > solution. > > I have no idea what you mean? The flag - as you have it now - should be > preserved, no? Perhaps if you moved the flag into tx_data then it > wouldn't be, and that's a good argument for not moving it? I was under the impression that the PS could write in part of the ieee80211_tx_info union which would be in conflict with the control part. But I've just rechecked the source and could not find anything like that. > > But maybe this feature is also not wanted anymore in the mac80211 > > driver. > > Well, I'm open to adding the code if you need it. Could consider VHT as > well, I guess. I personally don't have VHT hardware which would support injected frames with self chosen rates. So I cannot test VHT rate injection. > Adding the check to the fast-xmit path seems neither right nor > necessary though, since that shouldn't get invoked for injection to > start with? Ok, will be removed and I resent it as v2. Kind regards, Sven
Attachment:
signature.asc
Description: This is a digitally signed message part.
