On 2013-02-07 10:30 AM, Krishna Chaitanya wrote: > On Thu, Feb 7, 2013 at 2:53 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >> On Thu, 2013-02-07 at 14:49 +0530, Krishna Chaitanya wrote: >>> On Thu, Feb 7, 2013 at 1:50 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: >>> > On Thu, 2013-02-07 at 00:01 -0800, chaitanyatk@xxxxxxxxxxx wrote: >>> > >>> >>> > Hmm. I'm not exactly happy with using (one of) the last control flag for >>> > a pure debug facility. >>> > >>> Hmm...initially i tried to add qos header in the debugfs itself but to avoid >>> code redundancy went with the TX_CTL. But in either case we need some kind >>> of flag to skip adding the qos header by mac80211 (or) to set the AMSDU >>> bit in the qos control header. >> >> I guess the question is whether we really need this code in the tree at >> all? It seems like a (relatively) obscure debug feature for which I'm >> not sure we should touch the TX fastpath? > > AMSDU in itself is rarely used feature in 802.11. So your concern i s > understandable. > > But the problem is every time we have to test the Rx-AMSDU > which is mandatory for WFA 802.11n cert, we need to procure a adapter > which supports it, which is difficult. Thats the scenario we have faced > which lead us to work on this.With this feature in place we can use > any opensource adapter and driver for that purpose. > > Again, Its a trade off between stability and usability :-) How about injecting A-MSDU packets via cooked monitor mode or nl80211 frame tx and thus shifting the debug-only code into userspace? - Felix -- 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
