From: Jason Wang <jasowang@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu -netdev tun/tap support can't handle macvtap type devices
Date: Thu, 8 Dec 2016 09:53:51 +0800 [thread overview]
Message-ID: <0f77bab2-47c1-66ba-b89c-bd6d07c3e134@redhat.com> (raw)
In-Reply-To: <20161207142449.GC1476@redhat.com>
On 2016年12月07日 22:24, Daniel P. Berrange wrote:
> On Wed, Dec 07, 2016 at 02:21:24PM +0000, Peter Maydell wrote:
>> On 7 December 2016 at 14:07, Daniel P. Berrange <berrange@redhat.com> wrote:
>>> On Wed, Dec 07, 2016 at 12:30:31PM +0000, Peter Maydell wrote:
>>>> On 7 December 2016 at 12:04, Daniel P. Berrange <berrange@redhat.com> wrote:
>>>>> On Wed, Dec 07, 2016 at 12:01:14PM +0000, Peter Maydell wrote:
>>>>>> The usual suggested workaround is to use the -netdev fd option, like
>>>>>> fd=3 3<>/dev/tap$(< /sys/class/net/tap0/ifindex)
>>>>>> (which gets the shell to open the right /dev/tap device).
>>>>>> Unfortunately this isn't compatible with multi-queue support
>>>>>> because netdev complains
>>>>>> "ifname=, script=, downscript=, vnet_hdr=, helper=, queues=, fds=,
>>>>>> and vhostfds= are invalid with fd="
>>>>>> so you can't pass options like "queues=4"...
>>>>> FWIW you should be able to instead do
>>>>>
>>>>> fds=3 3<>/dev/tap$(< /sys/class/net/tap0/ifindex)
>>>>>
>>>>> 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 :-(
>
> Regards,
> Daniel
Yes, but not the time when multiqueue is introduced. I'm not sure how
much value we can gain from this, consider libvirt has already use fds
for years.
Thanks
prev parent reply other threads:[~2016-12-08 1:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-07 12:01 [Qemu-devel] qemu -netdev tun/tap support can't handle macvtap type devices Peter Maydell
2016-12-07 12:04 ` Daniel P. Berrange
2016-12-07 12:30 ` Peter Maydell
2016-12-07 14:07 ` Daniel P. Berrange
2016-12-07 14:21 ` Peter Maydell
2016-12-07 14:24 ` Daniel P. Berrange
2016-12-07 14:32 ` Peter Maydell
2016-12-08 1:52 ` Jason Wang
2016-12-08 15:37 ` Peter Maydell
2016-12-08 1:53 ` Jason Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f77bab2-47c1-66ba-b89c-bd6d07c3e134@redhat.com \
--to=jasowang@redhat.com \
--cc=berrange@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).