Hey,
please find below the notes from our last meeting. The next meeting is
on Monday Dec 9th, 10:00-12:00 CET
Best,
Hannes
## Meeting Nov 25th 10:00 - 12:00 CET
- Participants: Sam, Reynir, Hannes, Pierre
### OCaml 5
- https://github.com/mirage/ocaml-solo5/pull/134
- Sam continued and rebased that PR
- the strerror is actually used, it was marked as TODO (we need to
implement it)
- Virgile restarted last week the measures on the Mirage website, but we
don't have access to the Grafana dashboard
- Hannes reviewed some bits and pieces of the ocaml-solo5 PR
- The ocaml-src package relies on an extra file, META, that has been
moved to opam-source-archives
- There could either be a "echo ... > META" or a META.in file for the
ocaml-src package, hannes will take a look and propose PRs -- an empty
META file may be sufficient
- TODO: rebase the patches on 5.2.1
- question: what about the LICENSE if we take values (and comments) from
an existing project -- maybe we should copy the entire errno.h?
### unikraft
- there's something that works with networking (didn't look into block
devices yet)
### Results from performance experiments
- Pierre did some benchmarks
https://github.com/palainp/simple-fw/tree/no-cstruct
- running with solo5-spt as a Qubes guest
| Av. bandwitdh (Gbits/sec) | Ocaml 4.14.1 | Ocaml 5.2 | C
relay |
|---------------------------|--------------------|-----------------|-------------|
| Cstruct as BA | 1.16 | 1.12 |
1.58 |
| Cstruct as bytes | 1.42 | 1.41 |
1.58 |
- running with separate VMs (iperf client, bridge/firewall, iperf
server) resulted in the C implementation being slower than the MirageOS ones
- TODO someone else reproducing the benchmarks on a separate infrastructure
- TODO optimize the C implementation (?)
- We can use a bridge interface (brctl) with both network interfaces (so
we don't copy from kernel space to user space)
- TODO try with virtio
- Sam: maybe use sendfile? (that'd be an optimization for the C relay)
- To conclude, moving Cstruct from bigarray to bytes improves the
performance
- Hannes likes the simple-fw performance setup for the lower layers of
the network stack, we can learn a lot: different backends, flambda2,
trying out queueing (instead of one VMEXIT per packet send/recv)
- The remaining blocker for cstruct-as-bytes is the xen backend which
relies on non-moving page-aligned memory being passed around. We should
continue to work on adapting that code (to use io-page)
- Pierre also mentioned that we can look deeper into what allocations we
can remove to improve the performance
