From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56108)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mukawa@igel.co.jp>) id 1YxmZx-0001ES-Fj
	for qemu-devel@nongnu.org; Wed, 27 May 2015 21:25:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mukawa@igel.co.jp>) id 1YxmZu-0007zR-5c
	for qemu-devel@nongnu.org; Wed, 27 May 2015 21:25:49 -0400
Received: from mail-pa0-f45.google.com ([209.85.220.45]:35739)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mukawa@igel.co.jp>) id 1YxmZt-0007zL-WA
	for qemu-devel@nongnu.org; Wed, 27 May 2015 21:25:46 -0400
Received: by pacwv17 with SMTP id wv17so10815298pac.2
	for <qemu-devel@nongnu.org>; Wed, 27 May 2015 18:25:44 -0700 (PDT)
Message-ID: <55666E97.8020409@igel.co.jp>
Date: Thu, 28 May 2015 10:25:43 +0900
From: Tetsuya Mukawa <mukawa@igel.co.jp>
MIME-Version: 1.0
References: <1432538908-26298-1-git-send-email-mukawa@igel.co.jp>	
	<1432538908-26298-5-git-send-email-mukawa@igel.co.jp>	
	<55639E2E.9040604@redhat.com> <1432608391.2198.39.camel@igel.co.jp>
	<5563F695.2080706@igel.co.jp> <55646C91.4080409@redhat.com>
In-Reply-To: <55646C91.4080409@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC PATCH 4/4] vhost-user: Add new option to
 specify vhost-user backend supports
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eric Blake <eblake@redhat.com>
Cc: jasowang@redhat.com, n.nikolaev@virtualopensystems.com, qemu-devel@nongnu.org, stefanha@redhat.com

On 2015/05/26 21:52, Eric Blake wrote:
> On 05/25/2015 10:29 PM, Tetsuya Mukawa wrote:
>
>>>>>  { 'struct': 'NetdevTapOptions',
>>>>> @@ -2259,7 +2261,8 @@
>>>>>      '*vhostfd':    'str',
>>>>>      '*vhostfds':   'str',
>>>>>      '*vhostforce': 'bool',
>>>>> -    '*queues':     'uint32'} }
>>>>> +    '*queues':     'uint32',
>>>>> +    '*backend_features':'uint64'} }
>>>> Ewww. Making users figure out what integers to pass is NOT user
>>>> friendly.  Better would be an enum type, and make the parameter an
>>>> optional array of enum values.
>>> Thanks for your comments.=20
>>> I guess below may be good example. Is this same as your suggestion?
>>>
>>>  virtio-net-pci,netdev=3Dhostnet3,id=3Dnet3,gso=3Doff,guest_tso4=3Dof=
f,guest_tso6=3Doff
>>>
>>> So I will improve 'backend-features' like below.
>>>
>>>  backend-features=3Dgso=3Doff,guest_tso4=3Doff,guest_tso6=3Doff
>>>
>>> Also I will fix 'qapi-schema.json' to work like above.
>> I seems it's impossible to implement like above.
>> I may need to implement like below.
>>
>> virtio-net-pci,netdev=3Dhostnet3,id=3Dnet3,backend_gso=3Don,backend_gu=
est_tso4=3Don,backend_guest_tso6=3Don
> Or even:
>
> virtio-net-pci,netdev=3Dhostnet3,id=3Dnet3,backend.gso=3Don,backend.gue=
st_tso4=3Don,backend.guest_tso6=3Don
>
> Look at -device for how to set up nested structs using '.' for a nice
> hierarchy of options all belonging to a common substruct.
>

I appreciate for your suggestion.
I will check '-device' option, and implement like above in v2 patch.

Tetsuya