Fast usermode networking with QEMU

Fast usermode networking with QEMU

[Anders Pitman]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

I came across this blog post[0] concerning passt, which is an alternative usermode networking implementation for QEMU.

I'm working on a project that uses QEMU on Windows hosts running Linux guests. I'm trying to get faster usermode networking than is available with libslirp. My performance target is 200Mbps even on older or less powerful hardware, such as Celeron mini PCs. Currently I'm seeing 15-30MBps with libslirp.

It appears that passt doesn't currently support Windows, correct? Is there a guess as to how difficult that might be to implement? If the speedup is significant, I would be interested in taking a crack at adding Windows support.

Thanks,
//anders

[0]: http://blog.vmsplice.net/2021/10/a-new-approach-to-usermode-networking.html

[-- Attachment #2: Type: text/html, Size: 1119 bytes --]

Re: Fast usermode networking with QEMU

[Stefano Brivio]

Hi Anders,

On Mon, 23 May 2022 14:51:17 -0600
"Anders Pitman" <anders@apitman.com> wrote:

> I came across this blog post[0] concerning passt, which is an
> alternative usermode networking implementation for QEMU.

...and I just came across your email, entirely by chance. I'm not
actively monitoring this list most of the time.

> I'm working on a project that uses QEMU on Windows hosts running
> Linux guests. I'm trying to get faster usermode networking than is
> available with libslirp. My performance target is 200Mbps even on
> older or less powerful hardware, such as Celeron mini PCs. Currently
> I'm seeing 15-30MBps with libslirp.
> 
> It appears that passt doesn't currently support Windows, correct? Is
> there a guess as to how difficult that might be to implement? If the
> speedup is significant, I would be interested in taking a crack at
> adding Windows support.

I gave some quick comments about the challenges I see in the
perspective of a FreeBSD port at:
  https://bugs.passt.top/show_bug.cgi?id=6#c2

and I suppose a Windows port, by the way tracked at:
  https://bugs.passt.top/show_bug.cgi?id=8

could face similar challenges.

But from a quick browsing of the Winsock reference documentation months
ago, it actually looked easier because there seemed to be a description
of an equivalent for every bit of TCP socket information we're fetching
on Linux via TCP_INFO socket option.

I can try to remember/double check and give more details if it helps,
but if you're familiar with Windows development I suppose I wouldn't add
much value. :)

-- 
Stefano