| Dear Pierre,
While this is a good step forward, it is worth considering how to deal with the requirements of some backends for non-moving IO pages to pass through to the kernel/unikernel. This interface will force a copy, but perhaps that's ok. It should be possible to make OCaml 5 bytes non-moving with some consideration for the garbage collector, but I haven't had a chance to think through the details.
best, Anil
--
Anil Madhavapeddy, Professor of Planetary Computing
Computer Laboratory, University of Cambridge (cst.cam.ac.uk)
On Oct 1, 2024, at 4:02 PM, pierre.alain@xxxxxxx wrote:
Dear all,
Over the past few months, a large amount of work has been carried out to reduce the use of Cstruct.t. This was mainly driven by performances, as there were a lot of expensive allocations for small buffers (from 0 to a couple of bytes). Indeed, there were big performance improvements with mirage-crypto (which weren't limited to extracting Cstruct, but also algorithm improvements and a deeper thinking about allocations, like allocating a buffer once, and writing to it rather than allocating multiple buffers and concatenating them).
Now I'm wondering if this could be a time to extend this work of Cstruct removal with another API breakage. You can see at https://github.com/mirage/mirage-net/pull/25 a proposal for the new API. It's still conservative in term of "where each buffers would be allocated". Of course, if it is merged, there will be the need for lot of PR to make dependent libraries compliant with the new interface.
That's why I'm happy to ask your opinion on this possible step forward :)
Best,
Pierre
--
P.
|
