Hello,
below are the notes from the meeting. Next meeting in two weeks (since
it is not clear whether I'll be available, someone else needs to
organize it).
Participants: Pierre, Thomas G., Samuel, Virgile, Hannes, Fabrice
Agenda:
- network API thoughts https://github.com/mirage/mirage/issues/1550
- 4.5.2 release https://github.com/mirage/mirage/issues/1547 (with
questions about boot parameters)
- ocaml-solo5 and OCaml 5
Notes:
#### Network API questions
- Hannes: how did the current API occur? was it guided by performance
reasoning?
- Thomas: What API would you like to have?
- Hannes: Something that is more flexible where I don't need to
instantiate functors manually (but can pass callbacks)
- Thomas: Hard to find the right API due to efficiency. It was designed
at the same tim as openvswitch appeared
(https://github.com/mirage/ocaml-openflow).
- Hannes: maybe something like BPF (as tcpdump uses for filters) would
be nice: flexible and can compile to efficient code -- but there's no
OCaml implementation that I can find
- Thomas: did anyone look at the openflow implementation?
- Thomas: a bit more dynamic would be nice (liking adding a new callback
on events), but you've to design it properly to meet the performance goals)
- Hannes: for applications (web server etc.), the current API is ok, but
for lower layer things (DHCP, NAT, VPN), it is tedious
- Thomas: there's https://github.com/ygrek/ocaml-bpf
- Thomas: for vpnkit (https://github.com/moby/vpnkit/) we had to add
something to be more dynamic (like adding routes)
- Virgile: how hard would it be to implement an eBPF in OCaml
- Hannes: can't be that hard, maybe a weekend -- in the end you need the
parser for the rule language, and then a "compiler" that outputs
sequences of `Cstruct.get` and `equal` instructions
- Virgile: maybe the path forward is to go with a BPF implementation,
play around, look at performance and flexibility
#### 4.5.2 release
- Hannes: still waiting for some opam packages to be merged
- Hannes: the remaining question is when a mirage device can take some
runtime argument, should that be defined in the mirage package (the
alternative is that the keys are defined in each unikernel) -- e.g. not
done for git-over-ssh
- Thomas: maybe they can move to the ssh/git library? (Hannes: that'd be
nice, then they could have proper types as well (and not only string and
int)).
#### OCaml 5 and ocaml-solo5
- Sam: we're still waiting for some more tests (esp. looking at memory
profile of (long-running) unikernels)
- Sam: There are open PRs for fixing mirage-www
- Hannes: wants to test more, but no time before August. Would like to
deploy on retreat.mirage.io and look at the memory usage; but had issue
with monitoring. Really want to avoid memory usage increase.
- Thomas: has merged the opam-monorepo PR for ppx_lwt
- Pierre: uses the qubes-firewall with OCaml 5 since 2 weeks, works like
before -- already got ~10% more bandwidth
- Hannes: one thing could as well be to measure the mirage-www unikernel
side-by-side OCaml 4 and OCaml 5 (2 unikernels on two IP addresses)
- Hannes: I use mirage-monitoring to gather statistics, and then Grafana
and Influx -- at the same time albatross is gathering statistics from
the host system about the unikernel and reports these into the same
Influx database
- Thomas/Hannes: we want to have a Grafana for mirage.io on the
mirage-www host. If anyone has time to set this up, please volunteer for
doing that.
- Virgile: I can do that. Hannes: Please send me your ssh public key,
I'll set you up with an account. Virgile: sent it on Matrix
#### Unikraft update
- Sam: hope to have a first PoC for the OCaml-solo5 equivalent soon
(with qemu)
- Sam: question: is clang used for MirageOS compilations?
- Hannes: I use clang since a long time, and MirageOS compiles
(nowadays) fine with it. This doesn't mean that any unikraft & MirageOS
must be working on FreeBSD/clang
- Sam: unikraft seems to be Linux-specific
- Sam: had a small example for quite some time, try to automate the
things that need manual intervention (in respect to the build system etc.)
- Sam: unikraft releases often, their most recent release doesn't work
on my arm setup
- Sam & Fabrice: starting to work on the Mirage tool
- Thomas: a "HOWTO write a new MirageOS backend" (documentation) would
be a great outcome
- Sam: at configure time, you decide on the backend (qemu, firecracker,
kvm, xen)
#### next meeting in two weeks
