On 02/11/2013 06:28 PM, Markus Armbruster wrote:
> Commit 264986e2 extended NetdevTapOptions without updating the
> documentation. Hasn't been addressed since. Must fix for 1.4, in my
> opinion.
Will send a patch to fix this.
Thanks
>
> This is the offending patch:
>
> Jason Wang <jasow...@redhat.com> writes:
>
>> Recently, linux support multiqueue tap which could let userspace call
>> TUNSETIFF
>> for a signle device many times to create multiple file descriptors as
>> independent queues. User could also enable/disabe a specific queue through
>> TUNSETQUEUE.
>>
>> The patch adds the generic infrastructure to create multiqueue taps. To
>> achieve
>> this a new parameter "queues" were introduced to specify how many queues were
>> expected to be created for tap by qemu itself. Alternatively, management
>> could
>> also pass multiple pre-created tap file descriptors separated with ':'
>> through a
>> new parameter fds like -netdev tap,id=hn0,fds="X:Y:..:Z". Multiple vhost file
>> descriptors could also be passed in this way.
>>
>> Each TAPState were still associated to a tap fd, which mean multiple
>> TAPStates
>> were created when user needs multiqueue taps. Since each TAPState contains
>> one
>> NetClientState, with the multiqueue nic support, an N peers of NetClientState
>> were built up.
>>
>> A new parameter, mq_required were introduce in tap_open() to create
>> multiqueue
>> tap fds.
> [...]
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 3a4817b..cdd8384 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -2533,6 +2533,7 @@
>> 'data': {
>> '*ifname': 'str',
>> '*fd': 'str',
>> + '*fds': 'str',
>> '*script': 'str',
>> '*downscript': 'str',
>> '*helper': 'str',
>> @@ -2540,7 +2541,9 @@
>> '*vnet_hdr': 'bool',
>> '*vhost': 'bool',
>> '*vhostfd': 'str',
>> - '*vhostforce': 'bool' } }
>> + '*vhostfds': 'str',
>> + '*vhostforce': 'bool',
>> + '*queues': 'uint32'} }
>>
>> ##
>> # @NetdevSocketOptions
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
