|
From: | Jason Wang |
Subject: | Re: [Qemu-devel] qemu -netdev tun/tap support can't handle macvtap type devices |
Date: | Thu, 8 Dec 2016 09:52:07 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
On 2016年12月07日 22:32, Peter Maydell wrote:
On 7 December 2016 at 14:24, Daniel P. Berrange <address@hidden> wrote:On Wed, Dec 07, 2016 at 02:21:24PM +0000, Peter Maydell wrote:On 7 December 2016 at 14:07, Daniel P. Berrange <address@hidden> wrote:On Wed, Dec 07, 2016 at 12:30:31PM +0000, Peter Maydell wrote:On 7 December 2016 at 12:04, Daniel P. Berrange <address@hidden> wrote:note 'fds' plural, instead of 'fd'What's the difference between that and the "usual suggested workaround" I described above that doesn't work with queues=... ?It just seems the 'queues' param always wants you to use 'fds' instead of 'fd' - 'fds' takes a comma-separated list of FDs - one per queue and 'fd' only takes a single FD.Oh, I see. That seems a bit obscure :-)And pointless, because QemuOpts would have allowed use of 'fd' multiple times instead of inventing a new arg. fd=1,fd=3,fd=6 could have worked fine with multi-queue :-(I guess the best we could do now would be to make fd= and fds= synonyms with both supporting either comma-separated or being specified multiple times ?
When multiqueue were introduced, qemu does not support such kind of parameters. This maybe useful (or use fd[0],fd[1]), but I'm not sure this is really needed consider libvirt is in charge of doing such things now.
It's particularly confusing in this case that fd= doesn't work with queues=, because the user isn't trying to pass multiple fds, just the one is fine.
Since fd can only accept on file descriptor, so it implies 1 queue. For "fds", specifying queues seems redundant, since qemu can count the #fds by itself.
Thanks
thanks -- PMM
[Prev in Thread] | Current Thread | [Next in Thread] |