Actually the recipient part I can see be implemented in the user space MLME. The initiator part requires request from kernel to user space to start the BA negotiation. Still there is some amount internal state information that need to be passed back and forth that make user space MLME to be a long shot, bat eventually we get there. Dynamic algorithm look like best option to me as keeping underutilized stream only hurts the performance. User application may tune thresholds and timeouts and of course must tag the traffic. On 4/12/07, Simon Barber <simon@xxxxxxxxxxxxxxx> wrote:
There are several possible notification mechanisms - according to the application's needs. It could be part of tc - using a qdisc, or libpcap, or something hardwired into mac80211 or something else. Someone might want this controlled by a userspace application (e.g. video streaming). Someone else might want an automatic algorithm. Simon -----Original Message----- From: Tomas Winkler [mailto:tomasw@xxxxxxxxx] Sent: Wednesday, April 11, 2007 4:05 PM To: Simon Barber Cc: Michael Wu; mabbas; John W. Linville; linux-wireless@xxxxxxxxxxxxxxx; Jouni Malinen Subject: Re: [patch 2/5] Add basic support for IEEE 802.11n discovery and association So you monitor your traffic load in driver, then notify user space application which opens or tears down for you the BA stream? What would be the notification mechanism ? On 4/12/07, Simon Barber <simon@xxxxxxxxxxxxxxx> wrote: > Setup and tear down of BA should be done by userspace - actual > processing of the BA frames themselves should be done in mac80211. > This allows maximum flexibility from userspace to control the policy > of when to setup and teardown BA streams. > > Simon > > -----Original Message----- > From: Tomas Winkler [mailto:tomasw@xxxxxxxxx] > Sent: Wednesday, April 11, 2007 3:04 PM > To: Michael Wu > Cc: mabbas; John W. Linville; linux-wireless@xxxxxxxxxxxxxxx; Jouni > Malinen; Simon Barber > Subject: Re: [patch 2/5] Add basic support for IEEE 802.11n discovery > and association > > On 4/11/07, Michael Wu <flamingice@xxxxxxxxxxxx> wrote: > > On Wednesday 11 April 2007 16:04, mabbas wrote: > > > I am not familiar with userspace mlme what needed to be done? > > mac80211 has a userspace mlme mode which defers all things dealing > > with management frames to userspace (wpa_supplicant). It basically > > disables all the code in ieee80211_sta.c and routes management > > frames to a special interface where wpa_supplicant (or hostap) > > handles things. This is preferred and the ieee80211_sta.c code is > > there for > backwards compatibility. > > > > No major features should be added to the in-kernel MLME > > (ieee80211_sta.c) but even more importantly, your patch series does > > not provide the appropriate hooks for a userspace MLME to support a > driver using this 802.11n API. > > > > -Michael Wu > > > > > Meanwhile I don't see feasible user space implementation for this as > data packet classification is done in kernel. BACK streams are > dynamically opened and teared down per TID according current traffic > shape. > This is new feature and the user space handling is not well understand > yet. I suggest that we proceed with patches and let the evolution > making its steps. > > If someone has concrete suggestion on implementing it as user space > MLME I will be glad to hear. > 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
