qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 00/22] Multiqueue virtio-net


From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH V4 00/22] Multiqueue virtio-net
Date: Thu, 31 Jan 2013 23:04:23 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 01/31/2013 09:44 PM, Eric Blake wrote:
> On 01/31/2013 12:00 AM, Jason Wang wrote:
>> On 01/31/2013 02:29 AM, Eric Blake wrote:
>>> On 01/30/2013 04:12 AM, Jason Wang wrote:
>>>
>>>> With this changes, user could start a multiqueue virtio-net device through
>>>>
>>>> ./qemu -netdev tap,id=hn0,queues=2,vhost=on -device 
>>>> virtio-net-pci,netdev=hn0
>>>>
>>>> Management tools such as libvirt can pass multiple pre-created 
>>>> fds/vhostfds through
>>>>
>>>> ./qemu -netdev tap,id=hn0,fds=X:Y,vhostfds=M:N -device 
>>>> virtio-net-pci,netdev=hn0
>>> Do we really need specific fds= parsing, or can we reuse the existing
>>> -add-fd command line option to our advantage?  I guess what I'm asking
>>> is how hotplug will work; and if hotplug takes a file name, shouldn't
>>> the command line also take a name; and if the command line takes a name,
>>> what's wrong with:
>>>
>>> ./qemu -add-fd fdset=1,fd=X -add-fd fdset=2,fd=Y -add-fd fdset=3,fd=M
>>> -add-fd fdset=4,fd=N -netdev
>>> tap,id=hn0,fds=/dev/fdset/1:/dev/fdset/2,vhostfds=/dev/fdset/3:/dev/fdset/4
>>> -device virtio-net-pci,netdev=hn0
>>>
>> AFAIK, tap does not support fdset now, so this requirement is beyond the
>> scope of multiqueue itself. We can do this in the future. Btw does
>> libvirt support add-fd now?
> Anything that uses qemu_open() supports fdset now.  The question I'm
> asking is whether the command line has a way to pass /path/to/name
> (which can be presented as /dev/fdset/nnn for add-fd usage) now, or
> whether it only supports fds=integers.

Nothing special with 'fds' and 'vhostfds', it just split the params by
':' and pass them one by one through monitor_handle_fd_param() just like
"fd" and "vhostfd". So if 'fd' and 'vhostfd' supports /path/to/name, so
do 'fds' and 'vhostfds'.

So for command line, you do can pass /path/to/name to fd/vhostfd but it
won't work since monitor_handle_fd_param() can not handle it because 1)
it's not an integer 2) it was not named before. But for hotplug,
non-integers works since it has already named by getfd, so does fds and
vhostfds.

For management such as libvirt, what's needed is just to connect the
fdname with ':'.

>> For hotplug, it just work if you pass multiple file descriptors one by
>> one through getfd and then use fds=X:Y,vhostfds=M:N.
> For hotplug, you can't pass integers; you have to name the fds either
> way.  Either you name it with getfd, or you name it with add-fd.  But
> getfd is not as nice as add-fd when it comes to ensuring that fds are
> not leaked in qemu, even when the management app such as libvirt
> restarts.  Furthermore, if it is possible to specify taps by pathname
> instead of by fd inheritance, then using getfd means you have to support
> two different approaches in QMP to distinguish which string is being
> supplied, while supporting add-fd means you only have to support
> qemu_open() which handles both direct names and fd passing in a single
> string interface.
>
> As for libvirt support of add-fd, I'm currently working with Stefan
> Berger to get patches applied; the goal is tha libvirt 1.0.3 (end of
> February) will support add-fd.
>

Thanks, I know there are advantages of add-fd, but current tap does not
use qemu_open() which means it can't support fdset. We can add this in
the future.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]