On Tue, Sep 9, 2008 at 1:27 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2008-09-09 at 12:25 +0200, Johannes Berg wrote: >> On Tue, 2008-09-09 at 13:21 +0300, Tomas Winkler wrote: >> >> > > Right. And if mac80211 is the AP, then I don't see how the STA can start >> > > aggregation since I couldn't find where the relevant action frames are >> > > handled. But you said it's not part of the code now, so I couldn't find >> > > it anyway. >> > >> > That's probably the current situation. >> >> So back to square one, where should it be handled? Does it really make >> sense to let hostapd have influence over the decision, or should we just >> move the code that we have a bit and handle it in the kernel? After all, >> we do have all the code necessary to handle it, but it's currently >> restricted to STA mode, and I don't see a fundamental reason for that. In basic AP mode everything can be handled by hostapd. There are no performance sensitive management task, therefore the original mac80211 flow didn't rout management frames withing mac80211 mlme. But I see benefit of keeping for example BA handshake, BAR, and MS/MIMO PS (not implemented yet) inside mac. BA session requires knowledge of sequence counters, BAR handles reordering buffer. MS-PS requires knowledge of number or rx chains. It will expose too much guts to the users space. > In fact, what if we're in STA mode with userspace MLME? Do we want to > handle all that in userspace then? This doesn't seem sensible to me. Also in this case I would leave this particular features + 11h (channel switch, TPC) inside mac80211. 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
