No way to efficiently wait for crypto accelerator operations in HAL

[andresag01]

Description

• Type: Enhancement

---

Enhancement

When looking at the code for crypto hardware acceleration, we noticed that there are many locations where a command is issued to the accelerator, then the thread must must wait for the operation to be completed. The mbed TLS API is mostly synchronous, so for lack of an alternative mechanism, the thread simply is set to busy wait until the accelerator has finished. This behaviour is inefficient as those CPU cycles could be used to execute another thread instead of manually checking on a condition.

Suggested enhancement
An idea to avoid the busy waits mentioned above is to have some mechanism that enabled HAL code to issue a command for the accelerator or a peripheral and then wait on a condition that would be satisfied (e.g. by means of a semaphore) when the operation has completed.

Pros
Threads can more efficiently be scheduled and blocking in the form of busy waiting for events to occur can be avoided in a much easier way.

Cons
Probably there might be issues with backwards compatibility when adding this new feature.

[bulislaw]

That's a very good point, I would say we should think about using RTOS in HAL, but that cannot happen as long as we support mbed 2.
Maybe we can temporarily introduce a wrapper for semaphore that would expand to RTOS sempahore if present and to busy loop for mbed 2?

@sg- @c1728p9 @0xc0170
[Mirrored to Jira]

[0xc0170]

I would rather keep HAL API simple and build on top of it - provide functionality to allow to be running in background.

@andresag01 Where in HAL is this? Can you pinpoint to our code base?
[Mirrored to Jira]

[andresag01]

@0xc0170: The crypto hardware acceleration code is full of busy wait loops while we wait for the accelerator to complete commands. For example: here. Also consider looking at the open PRs for crypto hardware accelerator.
[Mirrored to Jira]

[pan-]

I would rather keep HAL API simple and build on top of it - provide functionality to allow to be running in background.

That wouldn't solve the issue with busy waiting i.e wasted CPU cycles which can be use for other processing or save power.

@bulislaw The event middleware offers an interesting solution which avoid wasting CPU cycles with or without the RTOS present (see here)

[Mirrored to Jira]

[0Grit]

The event middleware offers an interesting solution which avoid wasting CPU cycles with or without the RTOS present (see here)

+1 for anything that brings us back closer to the event driven dream
[Mirrored to Jira]

[pan-]

@loverdeg-ep The link I've posted is an implementation of a semaphore with or without the RTOS. I wasn't advocating for the direct use of the event middleware to solve that issue. Apologies for the unclear message.

I don't think the use of the event middleware would be a sensible decision at the HAL level. Of course it would be feasible to have asynchronous API at that level however, due to the synchronous nature of mbed tls functions, the glue sitting between mbed tls and the HAL would have to act like a semaphore/condition variable.

[Mirrored to Jira]

[0Grit]

@pan- Thanks for clarification; I wasn't necessarily implying that it be used directly either.
More so implying that preference is to keep things asynchronous and RTOS as optional as possible.
[Mirrored to Jira]