On Friday, February 22, 2013 07:04:39 PM Adrian Chadd wrote: > Hm, we need to use MIN(rxmax) and MAX(density) regardless, right? > > If an AP is transmitting to a STA that has a lower rxmax or higher > density, it should obey that. > > The same rules apply for mesh, ibss, tdma operational modes. > > So yes, what we should do is: > > * initialise rxmax/density with the VAP capabilities > * track what the remote node rxmax/density is > * have a couple of functions that return the density and rxmax based > on the destination node and current VAP config > * teach the 11n drivers to use that.
Don't make it to complex, it's one-liner, not sure it's worth a function. The STA case is handled here because there is no later position to do so, AP already told us what it is capable of (ni_htparams) now it's the STA's job to do the same. The AP case is handled somewhere else, assoc req I guess, and that just uses the VAP params to verify the limits aren't above device caps. Using plain ni_htparams after that is just fine. If also done right in STA mode, ni_htparams will always contain a value which doesn't exceed either the AP's or the STA's or the device's limits (might have to change the value exactly there), so, using it directly is fine in drivers. I don't want to get into IBSS mode just yet, it's way to complex to get my head around that atm. Though, I think, it's a per-node and not a global parameter so the handling should match that from the AP? -- Bernhard _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
