qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Yongji Xie <elohimes@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	zhangyu31@baidu.com, Xie Yongji <xieyongji@baidu.com>,
	lilin24@baidu.com, qemu-devel@nongnu.org, chaiwen@baidu.com,
	marcandre.lureau@redhat.com, nixun@baidu.com
Subject: Re: [Qemu-devel] [PATCH for-4.0 0/6] vhost-user-blk: Add support for backend reconnecting
Date: Thu, 13 Dec 2018 10:58:43 +0800	[thread overview]
Message-ID: <ce6eb03a-8157-bd4a-a467-9c2d6b2fa7fd@redhat.com> (raw)
In-Reply-To: <CAONzpcZ_RqUujdSoVCPUHH0A2g4hHY=oM9x-04e-6WugYFQOiw@mail.gmail.com>


On 2018/12/12 下午5:18, Yongji Xie wrote:
>>>> Ok, then we can simply forbid increasing the avail_idx in this case?
>>>>
>>>> Basically, it's a question of whether or not it's better to done it in
>>>> the level of virtio instead of vhost. I'm pretty sure if we expose
>>>> sufficient information, it could be done without touching vhost-user.
>>>> And we won't deal with e.g migration and other cases.
>>>>
>>> OK, I get your point. That's indeed an alternative way. But this feature seems
>>> to be only useful to vhost-user backend.
>> I admit I could not think of a use case other than vhost-user.
>>
>>
>>>    I'm not sure whether it make sense to
>>> touch virtio protocol for this feature.
>> Some possible advantages:
>>
>> - Feature could be determined and noticed by user or management layer.
>>
>> - There's no need to invent ring layout specific protocol to record in
>> flight descriptors. E.g if my understanding is correct, for this series
>> and for the example above, it still can not work for packed virtqueue
>> since descriptor id is not sufficient (descriptor could be overwritten
>> by used one). You probably need to have a (partial) copy of descriptor
>> ring for this.
>>
>> - No need to deal with migration, all information was in guest memory.
>>
> Yes, we have those advantages. But seems like handle this in vhost-user
> level could be easier to be maintained in production environment. We can
> support old guest. And the bug fix will not depend on guest kernel updating.


Yes. But the my main concern is the layout specific data structure. If 
it could be done through a generic structure (can it?), it would be 
fine. Otherwise, I believe we don't want another negotiation about what 
kind of layout that backend support for reconnect.

Thanks


>
> Thanks,
> Yongji

  reply	other threads:[~2018-12-13  2:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  6:35 [Qemu-devel] [PATCH for-4.0 0/6] vhost-user-blk: Add support for backend reconnecting elohimes
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 1/6] char-socket: Enable "wait" option for client mode elohimes
2018-12-06  7:23   ` Marc-André Lureau
2018-12-06  7:53     ` Yongji Xie
2018-12-06  9:31   ` Yury Kotov
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 2/6] vhost-user: Add shared memory to record inflight I/O elohimes
2018-12-06  7:19   ` Marc-André Lureau
2018-12-06  7:22     ` Yongji Xie
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 3/6] libvhost-user: Introduce vu_queue_map_desc() elohimes
2018-12-06  7:16   ` Marc-André Lureau
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 4/6] libvhost-user: Support recording inflight I/O in shared memory elohimes
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 5/6] vhost-user-blk: Add support for reconnecting backend elohimes
2018-12-06 12:21   ` Yury Kotov
2018-12-06 13:26     ` Yongji Xie
2018-12-06  6:35 ` [Qemu-devel] [PATCH for-4.0 6/6] contrib/vhost-user-blk: enable inflight I/O recording elohimes
2018-12-06  7:23 ` [Qemu-devel] [PATCH for-4.0 0/6] vhost-user-blk: Add support for backend reconnecting Marc-André Lureau
2018-12-06  7:43   ` Yongji Xie
2018-12-06  9:21 ` Yury Kotov
2018-12-06  9:41   ` Yongji Xie
2018-12-06  9:52     ` Yury Kotov
2018-12-06 10:35       ` Yongji Xie
2018-12-06 13:57 ` Jason Wang
2018-12-06 13:59   ` Michael S. Tsirkin
2018-12-10  9:32     ` Jason Wang
2018-12-12  2:48       ` Yongji Xie
2018-12-12  3:00         ` Jason Wang
2018-12-12  3:21           ` Yongji Xie
2018-12-12  4:06             ` Jason Wang
2018-12-12  6:41               ` Yongji Xie
2018-12-12  7:47                 ` Jason Wang
2018-12-12  9:18                   ` Yongji Xie
2018-12-13  2:58                     ` Jason Wang [this message]
2018-12-13  3:41                       ` Yongji Xie
2018-12-13 14:56                         ` Michael S. Tsirkin
2018-12-14  4:36                           ` Jason Wang
2018-12-14 13:31                             ` Michael S. Tsirkin
2018-12-06 14:00   ` Jason Wang
2018-12-07  8:56   ` Yongji Xie
2018-12-13 14:45 ` Michael S. Tsirkin
2018-12-14  1:56   ` Yongji Xie
2018-12-14  2:20     ` Michael S. Tsirkin
2018-12-14  2:33       ` Yongji Xie
2018-12-14 21:23         ` Michael S. Tsirkin
2018-12-15 11:34           ` Yongji Xie

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=ce6eb03a-8157-bd4a-a467-9c2d6b2fa7fd@redhat.com \
    --to=jasowang@redhat.com \
    --cc=chaiwen@baidu.com \
    --cc=elohimes@gmail.com \
    --cc=lilin24@baidu.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=nixun@baidu.com \
    --cc=qemu-devel@nongnu.org \
    --cc=xieyongji@baidu.com \
    --cc=zhangyu31@baidu.com \
    /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).