Re: upcoming MirageOS meeting 2022-09-07

[pierre.alain@xxxxxxx]

Sep 7, 2022, 17:18 by haesbaert@xxxxxxxxxxxxx:

> That looks painfully slow, it's sad that iperf doesn't report packets per 
> second but that's around ~5kpps at 1460B/frame.
> I'm also surprised your sender is not saturating gigabit, but I'd have to 
> check how iperf knows it was able to send out the packets, usually no one 
> cares about the sender as long as you saturate the link.
>
This connexion is shared in the hotel and not as fast as a home one but I don't 
have anything better :)
For the giga (un-)saturation, this probably can be explained by the sys-net vm 
where packets also have to transit in both cases (and take its taxe).

> I think I feel I owe an explanation since I frequently talk about how solo5 
> IO is slow but never explain why/how. First of all I don't mean this as a 
> bashing, I love solo5, the code was never intended to be optimized for 
> network performance. Also take this with a grain of salt, there can be 
> multiple things involved and it might be a bug somewhere completely 
> unrelated, the truth is I haven't run tests enough to understand how much of 
> the solo5 IO can be blamed, I just repeat this because "there might be 
> nothing wrong".
>
I didn't take your comment, in any case, as a bashing against solo5 but as an 
idea where to look for evolution and improvements, which, to me, is the right 
spirit :)

> I had a quick look at the xen code for the first time now, and it's quite 
> different from the rest, it has very little to do with how solo5 does IO the 
> ring management and IO code is in ocaml and I can't really reason about it 
> without a lot of time.
> At this point I'd try to turn the firewall into an "expensive cable" just 
> copy packets from input to output and get some idea of the baseline.
>
>
Not sure if you mean xen code as the hypersivor or mirage-xen code. The same 
xen code (as the hypervisor) is involved in both linux and mirage cases and 
should have the same behavior.

Best,

Pierre