On Fri, Sep 11, 2009 at 4:35 AM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Fri, Sep 11, 2009 at 3:23 AM, Luis R. Rodriguez > <lrodriguez@xxxxxxxxxxx> wrote: >> ath9k/ath9k/ath9k_htc. But -- is there really is a measurable cost >> penalty? >> >> This is why I asked if someone can test and give measurable >> differences over this. If there really isn't then that's not strong >> point against it. > > Honestly, it probably won't matter in the grand scheme of things, but I > think if you are proposing a patch that touches every hotpath in two > drivers, then you need to do the work to say "by the way, this has benefit > X which outweighs the very small (or absent) performance regression Y, > and here are the numbers. You're completely right, sorry about that. I thought the advantages would have been obvious but let me clarify them them: So far I've tested this with: time iw list dev wlan0 scan > /dev/null Both with and without the patches and the time it takes to scan, when not associated, remains the same. Granted I do have an Intel Core Duo 1.8 GHz, so if some others could test this on some embedded platforms that would be appreciated. The main added advantage to these changes is the possibility to now share hw access code between ath5k/ath9k. With the patches as-is you get one hot path on the driver, whether or not you use common hw code through ath.ko or through the driver's own hw code. It is unclear to me whether this has any measurable benefits so an alternative is to only use the common read/write ops on the common ath.ko. Although I don't see any measurable differences at the moment I suspect most people are inclined to leave hw access directly on the driver and only use common hw read/write ops for the common code. I'll respin these patches to do just that. Luis -- 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
