Hi, > We're considering redesigning how aggregation works on mac80211 to > ensure its vendor neutral and to remove as much as redundant code in > drivers. We'd like some feedback from people and driver developers, > even those who haven't *yet* posted their new shiny 11n drivers, like > Marvell or Ralink driver developers. Well technically speaking there are 2 Ralink drivers in the Kernel already which *should* support aggregation (rt61 and rt73). I'm sorry I have not read the entire thread on the new aggregation support yet, but I'll write what I know from rt61/rt73/rt2800 here anyway. :) > Ivo, are you familiar yet with how aggregation works on Ralink > hardware? Does the new 11n hardware require firmware? Specifically > we're curious about how the hardware queues are managed. Ralink defines 4 queues, 1 Management queue (can be abused as regular TX queue) and a Beacon queue. There is no such thing as seperate aggregation queues, as soon as the device wants to perform aggregation it grabs a normal entry from the TX queue, and assignes all frames to it. rt61: 5 addresses can be provided for Aggrated frames, I am not sure if the first is a header only frame or not. rt73: Not sure what should be done rt2800: 2 addresses can be provided, where the first is a header/descriptor only address. In the second address frames can be provided. Because the aggregated frame is created directly into a TX entry, no other frames should go through that queue until the aggregated frame has been completed. I'm afraid that is currently all the information I got at this time, It is only a little, but I never got around to fully look into the aggregation support, although I definately want it implemented in the drivers to increase the performance a bit. :) Ivo -- 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
