On Wed, 2011-09-21 at 12:03 +0300, Luciano Coelho wrote: > > 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. Of course, but sending half the info is not really an option I'm willing to consider :-) > > advantages of 2: > > + adds more generic filtering capability > > What do you mean here? I think we can have quite generic filtering in > both cases. True, but we won't do it if we don't need it here ;-) > > + 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. That's what I meant by the filtering. > > 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 Oh, that might be true. You might be able to fake it but that seems complex. > 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. Good points! I'm convinced :-) 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
