Boost clock rate during CPU-intensive TLS routines

[foogod]

When thinking about the recent "tls slow?" thread on the maillist, it occurred to me that a lot of the stuff that mbedTLS does is actually CPU-bound, and this is actually a perfect example of a good use case for the "clock doubling" capabilities built into the ESP8266.

We should look into potentially bumping the clock rate up to 160MHz whenever mbedTLS needs to do cryptographic operations which would otherwise be too slow. I'm not sure exactly the best way to implement this, as it would most likely require modifying the internals of mbedTLS itself to add calls to sdk_system_overclock / sdk_system_restoreclock in the right places.. I haven't looked at whether there's any mechanism already built into mbedTLS which might allow us to do hooks like this without modifying its source directly, though.. (Alternately, if not we might be able to come up with a hook mechanism which could be accepted upstream and we could then use so we wouldn't have to maintain a custom mbedTLS source..)

[projectgus]

I was wondering about this too, although I suspect it may also be thrashing on the SPI Flash. I have all of the equipment to measure this, I just haven't gotten to it yet!

A lot of people (especially using Arduino) seem to run their ESPs at 160MHz all the time. I'm not sure what the implications are (I guess some additional power consumption, AFAIK noone has measured how much.)

Thanks for flagging this as an issue to keep track of.

[projectgus]

(Adding a note that this overlaps with #82, to help keep track.)

[projectgus]

One more thought (sorry for the comment spam) is that in the context of a TLS connection we could probably get very close just wrapping an overclock around our own LWIP calls in
https://github.com/SuperHouse/esp-open-rtos/blob/master/extras/mbedtls/net_lwip.c
... because all of the calls that incur TLS operations effectively happen in response to a connect/tx/rx operation which goes through our LWIP layer there.