Re: [PATCHv3 3/4] qemu-kvm: vhost-net implementation

[Avi Kivity <avi@redhat.com>]

On 08/20/2009 08:57 PM, Mark McLoughlin wrote:
>    - I think /dev/vhost makes more sense - we shouldn't need to add
>      another character device if we implement kernel backends for other
>      virtio devices
>    

I'm of the opposite opinion - vhost-net and vhost-blk are related, but 
they're a lot more different than they are similar.

>    - I'd really like vhost to support a 'tap' mode, so that we can still
>      use a bridge if a NIC isn't available to be assigned. It would
>      result in this stuff getting much more testing. Options I see:
>
>         1) Add tap-like functionality to vhost
>         2) Add VHOST_NET_SET_TAP
>         3) Just tell people to set up a tap and bind a raw socket too it
>
>       IMHO, (2) makes the most sense - it should be much less exta kernel
>      code than (1), and it would be much more convenient than (3)
>    

What about connecting vhost-net to one end of a veth pair, and 
conencting the other end to a bridge?

>    - Distros will also need some way to have the module loaded if its
>      not built-in; best I can think of in Fedora is to stick it in
>      /etc/sysconfig/modules/kvm.modules
>
>      What would be nicer is if loading the kvm module could cause vhost
>      to be loaded. It's nice that vhost can be used without kvm, but I
>      think if kvm is loaded it's just very convenient to load vhost too.
>      See also the problems we've cause with needing mkinitrd/dracut
>      hacks by not having KVM_GUEST require VIRTIO_PCI
>    

Given that new userspace and a new kernel is needed, I don't see an 
issue with the /etc/sysconfig fix.

>> 2. disable tso, gso, lro, jumbo frames on the card
>>     (disabling lro + jumbo frames should be sufficient,
>>      haven't tested this)
>>      
> And this.
>
> If we leave that up to the user or the management app, we need to expose
> to them what features vhost supports so that they can know in future to
> stop disabling them.
>    

I imagine the merged version will support all those goodies.

-- 
error compiling committee.c: too many arguments to function