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@xxxxxxxxxx> wrote on 09/12/2010 05:16:37 PM: > >>>> > >>>>>"Michael S. Tsirkin"<mst@xxxxxxxxxx> > >>>>>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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
