On Wed, 2011-09-21 at 10:35 +0200, Johannes Berg wrote: > On Wed, 2011-09-21 at 11:19 +0300, Victor Goldenshtein wrote: > > > Just talked with Luciano, and we though to make this event more generic > > and to pass the whole BSS info instead of just BSSID and rssi, what do > > you think? > > I think there are two choices: > > 1) do what you say, and send the whole BSS info in the event > > 2) send a per-channel "scanned this channel" event, and allow filtering > the BSS dump per channel > > > There are a few trade-offs here: > > advantages of 1: > + info is directly available > + very fine-grained > > disadvantages of 1: > - lots of context switches, fairly expensive I just want to mention that these context switches will be there regardless of whether the full BSS info is passed or not. > advantages of 2: > + adds more generic filtering capability What do you mean here? I think we can have quite generic filtering in both cases. > + fewer context switches since retrieving BSS dump is limited & only > needs very few messages Indeed the number of switches will be smaller. To improve it further, as we discussed on IRC, we should also implement a per-channel BSS dump, otherwise we would have to retrieve the same data over an over again. > disadvantages of 2: > - not quite as fine-grained One more: - this requires HW support (which we don't have in wl12xx ;), unless SW scan is used > Personally, I prefer 2 because of the context switches issue, and > because I think there's little point in having so fine-grained > information. But I'm willing to concede that there may be a point in it, > more easily if you could explain why that's useful :-) I see your point about reducing the context switches while still increasing the granularity of scan results with this option 2, but I think it's not going to be that helpful. Sure we can stop the scan earlier if we find what we want, but the possibilities will be smaller. Also, with option 2, you may have more context switches too, if you're scanning on not-so-crowded areas. If we report results per-channel, we will always have at least 37 events (with 11a and 11bg), each triggering at least 3 context switches, because userspace requests the BSS dump separately. If we use per-results events, including all BSS info, we will have just as many context switches as there are results available. Thus, I think passing intermediate result events, as they come, is more flexible and efficient in normal situations. And if we really want to reduce the context switches and data copied from kernel to userspace, we also have the option of improving results filtering. We could make some similar "match" filters as I have recently implemented for sched_scans. -- Cheers, Luca. -- 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
