MirageOS biweekly calls - Nov 25th notes

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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