Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

[Paolo Bonzini]

Il 27/05/2013 18:18, Anthony Liguori ha scritto:
> Paolo Bonzini <address@hidden> 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.

Was zero-copy vmsplice/splice actually ever implemented?  I thought it
was reverted.

Paolo

>> 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
>>>
>>>