On Sunday 04 February 2007 19:31, Jon Smirl wrote: > On 2/4/07, Pavel Roskin <proski@xxxxxxx> wrote: > > In fact, Atheros chips are not that intelligent to be treated as FullMAC, but > > going to d80211 removes many chip specific features. > > What types of features are removed? For example Atheros turbo mode can > be treated like another PHY layer implementation. > > If it is just off-loading the implementation of standard behavior then > we may actually be better off ignoring this capability and > implementing the standard behavior in the host. > > It's not even clear to me that doing encryption is a wireless > co-processor is a win. It is almost certain that the host can perform > the same algorithms many times faster that an embedded wireless > processor. Moving encryption onto the host reduces the latency of the > connection. If creating and uploading the keys to the device is less work than doing crypto in software, then it is clearly a win. And that _is_ the case for bcm43xx (at least. I don't know about other devices' hwcrypto capabilities). Doing less on the CPU and more in hw is always a win. I'm not sure how you can say that you're not sure it is. ;) Additionally, doing crypto in the RX path (tasklet context) is not really optimal, from a latency point of view. But you can test it yourself. Enable/disable hwcrypto and watch how CPU load in "top" reacts. I did a quick test on my powerbook and software interrupt load decreases from about 30% to about 10% when switching from swcrypto to hwcrypto. I'd call that a significant win. And this 20% decrease is just the RX path. TX is done in process context (I think). -- Greetings Michael. - 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
