00:05 <sleepydog> wpcarro: i think you might need to specify ./hello_world.exe, or otherwise fully qualify the path

00:09 <sleepydog> and you don't install libraries with dune, you use a package manager like opam, or your OS package manager. in most cases you should have an "ocamlfind" command and "ocamlfind query PACKAGE" will tell you if you have PACKAGE installed in a place that dune can find it.

00:36 <wpcarro> ah okay

00:36 <wpcarro> I guess it's time for me to learn how the ocaml compiler resolves dependencies

00:39 <wpcarro> i'm using nixos, so things are slightly different here

00:52 <wpcarro> qwr do you have an example of how to invoke `ocaml ./script.ml` where `./script.ml` depends on (e.g.) Yojson?

00:53 <wpcarro> `ocamlfind list` reports yojson@2.0.2, and I see some yojson path on my $OCAMLPATH

00:57 <wpcarro> managed to resolve it in `utop` with `#require "yojson";;`

01:18 <wpcarro> https://gist.github.com/wpcarro/e276b84e5095c8d55faf9c555a867913

01:18 <wpcarro> is there a more ergonomic way to update an alist in ocaml?

01:32 <sleepydog> the first one looks fine to me. but the assoc function in the List module returns the leftmost item, so you could just add the new binding without removing the old one

05:13 <ski> wpcarro : if you're going to be keeping the old versions around, going back to them, then it's probably better not to remove the old pairs (sharing the tails to not generate as much intermediate space to be GCed). if you're otoh going forward adding new and new ones (with little to no backtracking / persistence needed), for a long time, you'll probably be wanting to clean up the old to remove space leaks

20:30 <saji> i am running into rather narrow opam version constraints for depext ... is there some replacement/alternative or should i just specify deps in a makefile?

20:49 <saji> hannes: someone just tossed https://github.com/mirage/qubes-mirage-firewall/issues/130 at me ... and after the usual "briefly getting stuck in opam dependency hell" i have a flambda build ... and now wondering how to properly benchmark this ...

20:52 <saji> hannes: tangent ... mirage-firewall should just stop checking checksums entirely, see lengthy "why ipv6 dropped the ip header checksum field" for reasons ...

21:17 <haesbaert> saji: you want a firewall to stop checking tcp checksums ?

21:18 <olle> Hmmm

21:18 <olle> Can Menhir do "not this token"?

21:18 <saji> haesbaert: that would be a sideshow, but yes.

21:18 <haesbaert> so I'm missing, what is the main show ?

21:20 <saji> haesbaert: #qubes thread about mirage-firewall cpu usage. which revealed two ways (+flambda and --allocation-policy=best-fit) "without" functional changes, but also reminded me of checksum checks on intermediate devices being useless.

21:21 <haesbaert> why are they useless ?

21:23 <saji> haesbaert: for all the reasons laid out around IPv6 not _having_ checksums. (mainly "bandwidth" being a much smaller problem than "cpu" these days)

21:24 <saji> layer 4/5 checksums _are_ still useful ... but only need to be checked by the layer 4/5 endpoints. this is about layer 3 checksums.

21:25 <haesbaert> so basically I have an endpoint with a slightly broken network stack that fails to do proper ip checksuming, so Iremove it from my firewall ?

21:26 <haesbaert> assume the other side is also sending udp without csum (which is still valid)

21:27 <saji> yes/no/mebbe? (i am not sure about your scenario there) ... the main point around the removal of l3 checksums when designing ipv6 (afair) was that accidental corruptions are rare, and just forwarding these rare packets and have them discarded by the endpoints is overall a whole lot easier than having every intermediate node do a check.

21:28 <haesbaert> (not even counted the plethora of network cards that produce a broken checksum)

21:28 <haesbaert> I just find it weird to be permissive in a firewall with sightly corrupt packets :D

21:28 <saji> (the "broken checksums" you see when using tcpdump on modern HW is an artifact that is not actualy a bad checksum.)

21:28 <haesbaert> no, it's actualy broken

21:29 <haesbaert> ix(4) with every model before x540 for anything other than IP and UDP

21:29 <haesbaert> say OSPF packets get a broken computed checksum and we have to fix it in the driver

21:29 <haesbaert> I mean other than TCP and UDP

21:29 <haesbaert> mistyped

21:29 <saji> "sniff on involved host is bad" is an unrelated pet-peeve of mine. :D

21:30 <haesbaert> realtek8139 produces broken checksums on scathered gathered segments also

21:30 <saji> 8139 is rather ... basic afair? does that even have checksum offloading?

21:31 <haesbaert> yeah, 39 is the gigabit right ? or 69 ? whatever the gigabit was called

21:31 <haesbaert> the gigabit was not as bad as the fast one

21:32 <saji> 39 is FE, 69 is GE

21:32 <haesbaert> ah ! yes, 69 then

21:32 <haesbaert> it even does udp and tcp

21:32 <haesbaert> ifp->if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_TCPv4 |

21:32 <haesbaert> IFCAP_CSUM_UDPv4;

21:33 <saji> otoh, i have also seen "server grade" intel nics causing on-receive corruption. (because it did the checksum-checks (correctly), and then dma-wrote things in the wrong places...)

21:33 <haesbaert> I wrote drivers for ixl(4), for a couple of years, it was the most bugged device I've ever seen

21:33 <haesbaert> like the big 50gbit ones

21:34 <haesbaert> ixl = intel 700

21:34 <saji> for which my executive summary still is ... yeah, its a shitshow, just do app level checks where you can, trust no one, but we shouldnt bog down every node in the path by doing very redundant math on each packet.

21:34 <haesbaert> half the fixes were "put a delay here"

21:34 <haesbaert> used to be much better, now it's a shit show, welcome to the future

21:36 <saji> on the not qubes/mirage/ocaml side of things, i am currently writing low-level code for xl710 (40G) and e810 (100g) that is used in production. :D

21:36 <haesbaert> oh nice, I wrote xl710

21:36 <haesbaert> GOOD LUCK, terrible chip :D

21:41 <saji> but the main reason for showing up here is really "wth is with depext opam version limits" and general barking at hannes for mirage-firewall reasons. :D

21:43 <haesbaert> can you link the qubes thread though ?

21:44 <saji> for the "performance" part, pretty much just the one i linked earlier: https://github.com/mirage/qubes-mirage-firewall/issues/130

21:45 <haesbaert> pierre alain did some tests a couple of weeks ago and he was getting 6kpps :/

21:45 <saji> which suggests +flmabda and --allocation-policy=best-fit ... managed to build with +flambda (after the above-mentioned opam/depext wrangling)

21:47 <saji> but i am still unsure how to properly benchmark this.

21:47 <saji> (as in, i can confirm it builds and passes functional testing, but i am unsure if it had any changes wrt performance)

21:56 <hannes> saji: so we did benchmarks with iperf3 on either side of the firewall...

21:57 <hannes> and the build was with 4.14 and no flambda (and the allocation-policy=best-fit is the default these days (since 4.12 or 4.13)

21:57 <saji> hannes: so just two linux vms with a mirage-fw between them and see what througput i get?

21:57 <hannes> saji: yes

21:58 <hannes> I'm all for not doing ip-level checksum computations, IIRC the receiving side always ignored mismatches anyways...

21:59 <hannes> but I've had enough computer for today... will take a look maybe tomorrow...

21:59 <saji> hannes: thanks for the reply, i will try some "man iperf3" this weekend. fly safe!

22:55 <saji> hannes: only minor diff between 20220527 no-flambda build (699 Mbps) vs 20221014 with-flambda (729 Mbps)