On Fri, 2011-11-04 at 09:17 -0700, Ben Greear wrote: > >>> The AMPDU density should only allow increasing. > >>> > >>> I think a lot of this validation should live in cfg80211 so if another > >>> driver wants to implement it, this kind of thing is already covered. > >> > >> The ath9k driver supports 0, and then every value that corresponds to 1us or higher. > >> If you set it to 1/2us, for instance, it just quietly rounds up to 1us. It defaults > >> to 8, so it appears valid to decrease or increase this value. > > > > What quietly rounds up? > > > > If it defaults to 8 then I'm sure there's a reason for it, such as the > > crypto engine not being fast enough and needing 8us buffer between > > frames. As such, I really don't think decreasing it is valid. > > See this code in ath9k, top of main.c. It appears to support more > than the default of 8. I tested it out, and it appears to work > when set to lower values. I am disabling hw-crypt since I need > multiple VIFS, but not sure that matters or not. > > static u8 parse_mpdudensity(u8 mpdudensity) Well, this is used for TX. You're advertising the value for RX. Advertising a smaller value may work for you -- but only if the AP uses something larger anyway. It's free to do this. The code you quoted implements this -- it looks at what the min spacing is the peer wants, and then uses something bigger. So I still stand by what I said earlier -- you should not allow advertising a smaller value than the hardware wanted to use initially. If the AP doesn't use that smaller value, all is well, but if it actually uses a smaller value then the hardware might fall over. johannes -- 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
