Re: [RFC PATCH 1/4] Add a new API to virtio-pci

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Sep 13, 2010 at 12:40:11PM -0500, Anthony Liguori wrote:
> On 09/13/2010 11:30 AM, Michael S. Tsirkin wrote:
> >On Mon, Sep 13, 2010 at 10:59:34AM -0500, Anthony Liguori wrote:
> >>On 09/13/2010 04:04 AM, Michael S. Tsirkin wrote:
> >>>On Mon, Sep 13, 2010 at 09:50:42AM +0530, Krishna Kumar2 wrote:
> >>>>"Michael S. Tsirkin"<mst@redhat.com>   wrote on 09/12/2010 05:16:37 PM:
> >>>>
> >>>>>"Michael S. Tsirkin"<mst@redhat.com>
> >>>>>09/12/2010 05:16 PM
> >>>>>
> >>>>>On Thu, Sep 09, 2010 at 07:19:33PM +0530, Krishna Kumar2 wrote:
> >>>>>>Unfortunately I need a
> >>>>>>constant in vhost for now.
> >>>>>Maybe not even that: you create multiple vhost-net
> >>>>>devices so vhost-net in kernel does not care about these
> >>>>>either, right? So this can be just part of vhost_net.h
> >>>>>in qemu.
> >>>>Sorry, I didn't understand what you meant.
> >>>>
> >>>>I can remove all socks[] arrays/constants by pre-allocating
> >>>>sockets in vhost_setup_vqs. Then I can remove all "socks"
> >>>>parameters in vhost_net_stop, vhost_net_release and
> >>>>vhost_net_reset_owner.
> >>>>
> >>>>Does this make sense?
> >>>>
> >>>>Thanks,
> >>>>
> >>>>- KK
> >>>Here's what I mean: each vhost device includes 1 TX
> >>>and 1 RX VQ. Instead of teaching vhost about multiqueue,
> >>>we could simply open /dev/vhost-net multiple times.
> >>>How many times would be up to qemu.
> >>Trouble is, each vhost-net device is associated with 1 tun/tap
> >>device which means that each vhost-net device is associated with a
> >>transmit and receive queue.
> >>
> >>I don't know if you'll always have an equal number of transmit and
> >>receive queues but there's certainly  challenge in terms of
> >>flexibility with this model.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >Not really, TX and RX can be mapped to different devices,
> 
> It's just a little odd.  Would you bond multiple tun tap devices to
> achieve multi-queue TX?  For RX, do you somehow limit RX to only one
> of those devices?

Exatly in the way the patches we discuss here do this:
we already have a per-queue fd.

> If we were doing this in QEMU (and btw, there needs to be userspace
> patches before we implement this in the kernel side),

I agree that Feature parity is nice to have, but
I don't see a huge problem with (hopefully temporarily) only
supporting feature X with kernel acceleration, BTW.
This is already the case with checksum offloading features.

> I think it
> would make more sense to just rely on doing a multithreaded write to
> a single tun/tap device and then to hope that in can be made smarter
> at the macvtap layer.

No, an fd serializes access, so you need seperate fds for multithreaded
writes to work.  Think about how e.g. select will work.

> Regards,
> 
> Anthony Liguori
> 
> Regards,
> 
> Anthony Liguori
> 
> >or you can only map one of these. What is the trouble?
> >What other features would you desire in terms of flexibility?
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html