On Mon, May 27, 2013 at 11:34:09AM +0200, Stefan Hajnoczi wrote: > On Sun, May 26, 2013 at 11:32:49AM +0200, Luke Gorrie wrote: > > Stefan put us onto the highly promising track of vhost/virtio. We have > > implemented this between Snabb Switch and the Linux kernel, but not > > directly between Snabb Switch and QEMU guests. The "roadblock" we have hit > > is embarrasingly basic: QEMU is using user-to-kernel system calls to setup > > vhost (open /dev/net/tun and /dev/vhost-net, ioctl()s) and I haven't found > > a good way to map these towards Snabb Switch instead of the kernel. > > vhost_net is about connecting the a virtio-net speaking process to a > tun-like device. The problem you are trying to solve is connecting a > virtio-net speaking process to Snabb Switch. > > Either you need to replace vhost or you need a tun-like device > interface. > > Replacing vhost would mean that your switch implements virtio-net, > shares guest RAM with the guest, and shares the ioeventfd and irqfd > which are used to signal with the guest. At that point your switch is > similar to the virtio-net data plane work that Ping Fan Liu is working > on but your switch is in a separate process rather than a thread. > > How does your switch talk to hardware?
Yes that's my question as well. > If you have userspace NIC > drivers that bypass the Linux network stack then the approach I > mentioned fits well. > > If you are using the Linux network stack then it might be better to > integrate with vhost maybe as a tun-like device driver. > > Stefan Maybe you should bind macvtap passthrough mode to veth. packet socket backend doesn't support TSO at this point, so it's slower. -- MST
