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, [email protected] 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. >
