On Tue, Sep 9, 2008 at 11:20 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2008-09-09 at 11:14 +0300, Tomas Winkler wrote: > >> >> The current design assumes that hostapd takes care of all management >> >> frames, so eyes, these would need to go to hostapd for processing and >> >> then setup back to mac80211 through some new command.. >> > >> > Well we can always pick out those action frames in the kernel if we want >> > to, that's not the problem, is it? >> >> We've indeed has kept inside just BA session action frames. > > Hmm? I don't think I understand what you're trying to say. Meaning that other management frames are forward to user space while BA action frames are treated inside mac80211. > >> > Should the design be changed? It seems that this is more related to the >> > rate scale algorithm and the "can we support aggregation for this STA" >> > question, both of which we currently have information about in the >> > kernel and not hostapd. >> >> The decision might come both from RS and hostapd. RS just have more >> info whether there will be gain from aggregation. When throughput is >> not high enough it's just an overhead. Though some APs open session >> immediately uppon association without and RS decision. >> Our design is that BA can be triggered not only for RS. > > Well yeah, but I'm not sure we really want to add API to cfg80211 for > this. It's not exactly hard to, but right now I don't see how hostapd > would influence the decision. > > Also, I'm not talking about the AP triggering the aggregation session, > this is entirely done with the rate scaling right now, but about an > associated STA wanting to start an aggregation session. Aren't > aggregation sessions always triggered by whoever wants to send? So if a > STA notices it has lots of upload going on it could want to trigger a BA > session, which is something we don't currently support afaict. In iwl-agn-rs.c There is not difference if the peer is STA or AP. So we support this already. Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
