As unikraft, we increase the ringbuffer to have a better throughput on our network device

[dinosaure]

As spotted here: https://github.com/unikraft/unikraft/blob/staging/drivers/virtio/ring/virtio_ring.c#L54. The throughput up to ~300MB/s instead of 260MB/s (/cc @shym who did some benchmarks on hvt).

[Kensan]

The comment should probably also be adjusted (or dropped) to reflect the change.

[shym]

I’ve added solo5-virtio to the network benchmarks we had run and ran it both with the released Solo5 and this PR. I get the following results.

@dinosaure: did you see better results for this PR in your tests? (in particular, I don’t think the difference is significant)
@Firobe: are the baseline results for solo5-virtio similar to what you had measured?
(And sorry if you saw the first draft of this message, I had used the wrong measures for some results)

[dinosaure]

I need to check but I'm currently on several fronts and mostly about on utcp. It's hard to bisect the true bottleneck between unikraft/solo5. I need to check also if Unikraft sets the TCO or not (despite Solo5 which does nothing). A quick look tells me that the ring queue of solo5-virtio is not so different from unikraft but I'm not an expert of such target and I need to double check several implementations (like the one from FreeBSD).

I also would like to ping @ricarkol who did the initial implementation of virtio but if he does not have the time to look on it (nor the interest), it's completely understandable.

[Firobe]

@Firobe: are the baseline results for solo5-virtio similar to what you had measured? (And sorry if you saw the first draft of this message, I had used the wrong measures for some results)

Yes, I have similar results (included below), including the non-significant difference for this PR. Now keep in mind this specific benchmark measures a relatively narrow use case (mostly receiving data), and different tests might bring more significant improvements out.

My results