Hi Simon,
I appreciate I'm coming very late to this discussion, but I want to make a point and suggestion.
Well, I don't think we had reached a clear consensus yet, so it's not too late to explore more options!
These are very similar points to those Manuel was making to remove the feature in the first place - however - short of investing the time in rewriting the asymmetric functions, what we could do as a quick fix is to replace the existing memory code with a block allocation scheme - which should be much faster, speed up the asymmetric functions (in theory), avoid fragmentation, be more deterministic, and a better fit for embedded applications. That could then become the basis of the library for other projects too.
I think compared to our existing allocator, that would indeed be an improvement, and as you say possibly a "quick fix" for some of the performance issues of our asymmetric crypto (esp. ECC)... for people who use our allocator. I'm still under the impression they're a minority of users, even in the embedded world.
I think it comes back to a point we touched on earlier in the thread: what other allocators are available, and how do they compare to the design you have in mind? If existing allocators in popular embedded libc implementations already handle small allocations efficiently, then people are probably better off using them.
I wouldn't mind contributing such a feature, as I had to write something very similar last week anyway.
If I do it - will you accept it?
Thanks for the offer! Unfortunately I think it's hard to give you a clear yes or no answer at this point.
Speaking only for myself (others in the team may disagree and are welcome to say so in reply), I'm a bit concerned that for a "quick fix" it would represent a significant review effort: there are obvious security implications, it would be a complete re-design of a whole module, and I'm not sure how many of the potential reviewers are very familiar with allocators (I know I'm not). Considering we already have a number of significant contributions that we just can't review as soon as we'd like, I'd be concerned adding another one.
Adding to that concern is the fact that at this point it's still not clear to me if in the long-term we want to keep maintaining this, or use some existing allocator, or move it to a separate project possibly maintained by another team.
Would your offer still stand in a couple of months, when the future of the module is perhaps a bit clearer, and when we've hopefully cleared a few of the long-standing large PR awaiting review?
Thanks, Manuel.
Hi Manuel,
On 11/05/2020, 10:45, "Manuel Pegourie-Gonnard" Manuel.Pegourie-Gonnard@arm.com wrote:
> These are very similar points to those Manuel was making to remove the feature > in the first place - however - short of investing the time in rewriting the > asymmetric functions, what we could do as a quick fix is to replace the > existing memory code with a block allocation scheme - which should be much > faster, speed up the asymmetric functions (in theory), avoid fragmentation, be > more deterministic, and a better fit for embedded applications. That could > then become the basis of the library for other projects too. > I think compared to our existing allocator, that would indeed be an improvement, and as you say possibly a "quick fix" for some of the performance issues of our asymmetric crypto (esp. ECC)... for people who use our allocator. I'm still under the impression they're a minority of users, even in the embedded world.
I would anticipate use of the allocator to actually speed up most platforms, as it will be faster than malloc. Block allocators can be inefficient in their use of RAM but are often used where performance matters. They are not just the domain of embedded software. I'm seen them appear in SQL server software, drivers, and game software. It's a common technique.
So the intention here is that enabling the feature should see a performance improvement but possibly at the cost of RAM efficiency. (It depends how well tuned it is).
I think it comes back to a point we touched on earlier in the thread: what other allocators are available, and how do they compare to the design you have in mind? If existing allocators in popular embedded libc implementations already handle small allocations efficiently, then people are probably better off using them.
I think this goes back to Dan's point.
There are other options out there - and people can configure the library to use them already.
The choice here was to keep the existing memory manager, or replace it with something faster, more deterministic and safer - predicated on the decision to keep support for a memory manager or not.
If you want or need to keep it - let's turn it to our advantage, and improve it, and make it the library faster through its use.
Would your offer still stand in a couple of months, when the future of the module is perhaps a bit clearer, and when we've hopefully cleared a few of the long-standing large PR awaiting review?
I have no plans on starting it for a while. I need to clear down my own PR backlog before I start something new.
Regards
Simon
mbed-tls@lists.trustedfirmware.org
-
Manuel Pegourie-Gonnard -
Simon Butcher