[Ovmsdev] Time for release 3.2.016?

[Stephen Casner]

On Fri, 12 Feb 2021, Michael Balzer wrote:

> as written before, higher base memory footprint is probably OK but needs to be
> tested on complex vehicles. So I suggest we do that before finalizing 3.2.016.

There seemed to be no response when that test was offered on a
separate branch.  Shall I increase the NetMan stack size now on master
so all the cars (that have active developers) can test it?

> Mongoose SSL connects also are slow, speeding them up would have a broader
> effect. But mongoose won't benefit from wolfSSL in internal RAM, as it's using
> mbedTLS supplied by the esp-idf.

Is mbedTLS configured to use heap instead of stack?

> What do you think, is there a chance we could reduce overall memory footprint
> _and_ gain speed for all SSL connects if we change mongoose to use wolfSSL?

It does seem inefficient in at least the code size dimension to have
multiple implementations of equivalent functionality, although I have
limited that by explicitly including only those source files from
wolfssl that are required by wolfssh.  So switching mongoose to use
wolfSSL would require increasing that set.  I'd be happy to try that.

> This comparison indicates wolfSSL is normally much more RAM efficient than
> mbedTLS:
> https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_tls.html#comparison-between-mbedtls-and-wolfssl

It would be nice if that comparison stated timings as well.

> Maybe discarding mbedTLS frees enough memory to put wolfSSL into internal RAM?

I would think that we don't have mongoose SSL processing and wolfSSL
processing happening at the same time.  If that's true, then the
switch would not help stack usage.  Do you know?

                                                        -- Steve