Paolo Bonzini <pbonz...@redhat.com> writes: > Il 27/05/2013 11:34, Stefan Hajnoczi ha scritto: >> 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. >> >> How does your switch talk to hardware? > > And also, is your switch monolithic or does it consist of different > processes? > > If you already have processes talking to each other, the first thing > that came to my mind was a new network backend, similar to net/vde.c but > more featureful (so that you support the virtio headers for offloading, > for example). Then you would use "-netdev snabb,id=net0 -device > e1000,netdev=net0".
It would be very interesting to combine this with vmsplice/splice. > It would be slower than vhost-net, for example no zero-copy > transmission. With splice, I think you could at least get single copy guest-to-guest networking which is about as good as can be done. Regards, Anthony Liguori >> 3. Use the kernel as a middle-man. Create a double-ended "veth" >> interface and have Snabb Switch and QEMU each open a PF_PACKET >> socket and accelerate it with VHOST_NET. > > As Michael, mentioned, this could be macvtap on the interface that you > have already created in the switch and passed to vhost-net. Then you do > not have to do anything in QEMU. > > Paolo > >> 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 >> >>
