From: Yongji Xie <elohimes@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Coquelin, Maxime" <maxime.coquelin@redhat.com>,
"Yury Kotov" <yury-kotov@yandex-team.ru>,
"Евгений Яковлев" <wrfsh@yandex-team.ru>,
qemu-devel <qemu-devel@nongnu.org>,
zhangyu31@baidu.com, chaiwen@baidu.com, nixun@baidu.com,
lilin24@baidu.com, "Xie Yongji" <xieyongji@baidu.com>
Subject: Re: [Qemu-devel] [PATCH v4 for-4.0 2/7] vhost-user: Support transferring inflight buffer between qemu and backend
Date: Tue, 15 Jan 2019 22:18:20 +0800 [thread overview]
Message-ID: <CAONzpcbnGbe-qjZdiBdjrrWbnhCBy+zGTtZ_qOjNoBecC+1r6A@mail.gmail.com> (raw)
In-Reply-To: <20190115075022-mutt-send-email-mst@kernel.org>
On Tue, 15 Jan 2019 at 20:54, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jan 15, 2019 at 02:46:42PM +0800, Yongji Xie wrote:
> > On Tue, 15 Jan 2019 at 06:25, Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Wed, Jan 09, 2019 at 07:27:23PM +0800, elohimes@gmail.com wrote:
> > > > @@ -382,6 +397,30 @@ If VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD protocol feature is negotiated,
> > > > slave can send file descriptors (at most 8 descriptors in each message)
> > > > to master via ancillary data using this fd communication channel.
> > > >
> > > > +Inflight I/O tracking
> > > > +---------------------
> > > > +
> > > > +To support slave reconnecting, slave need to track inflight I/O in a
> > > > +shared memory. VHOST_USER_GET_INFLIGHT_FD and VHOST_USER_SET_INFLIGHT_FD
> > > > +are used to transfer the memory between master and slave. And to encourage
> > > > +consistency, we provide a recommended format for this memory:
> > >
> > > I think we should make a stronger statement and actually
> > > just say what the format is. Not recommend it weakly.
> > >
> >
> > Okey, will do it.
> >
> > > > +
> > > > +offset width description
> > > > +0x0 0x400 region for queue0
> > > > +0x400 0x400 region for queue1
> > > > +0x800 0x400 region for queue2
> > > > +... ... ...
> > > > +
> > > > +For each virtqueue, we have a 1024 bytes region.
> > >
> > >
> > > Why is the size hardcoded? Why not a function of VQ size?
> > >
> >
> > Sorry, I didn't get your point. Should the region's size be fixed? Do
> > you mean we need to document a function for the region's size?
>
>
> Well you are saying 0x0 to 0x400 is for queue0.
> How do you know that's enough? And why are 0x400
> bytes necessary? After all max queue size can be very small.
>
>
OK, I think I get your point. So we need something like:
region's size = max_queue_size * 32 byte + xxx byte (if any)
Right?
>
> > >
> > > > The region's format is like:
> > > > +
> > > > +offset width description
> > > > +0x0 0x1 descriptor 0 is in use or not
> > > > +0x1 0x1 descriptor 1 is in use or not
> > > > +0x2 0x1 descriptor 2 is in use or not
> > > > +... ... ...
> > > > +
> > > > +For each descriptor, we use one byte to specify whether it's in use or not.
> > > > +
> > > > Protocol features
> > > > -----------------
> > > >
> > >
> > > I think that it's a good idea to have a version in this region.
> > > Otherwise how are you going to handle compatibility when
> > > this needs to be extended?
> > >
> >
> > I have put the version into the message's payload: VhostUserInflight. Is it OK?
> >
> > Thanks,
> > Yongji
>
> I'm not sure I like it. So is qemu expected to maintain it? Reset it?
> Also don't you want to be able to detect that qemu has reset the buffer?
> If we have version 1 at a known offset that can serve both purposes.
> Given it only has value within the buffer why not store it there?
>
Yes, that looks better. Will update it in v5.
Thanks,
Yongji
next prev parent reply other threads:[~2019-01-15 14:18 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-09 11:27 [Qemu-devel] [PATCH v4 for-4.0 0/7] vhost-user-blk: Add support for backend reconnecting elohimes
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 1/7] char-socket: Enable "nowait" option on client sockets elohimes
2019-01-10 12:49 ` Daniel P. Berrangé
2019-01-10 13:19 ` Yongji Xie
2019-01-10 13:24 ` Daniel P. Berrangé
2019-01-10 14:08 ` Yongji Xie
2019-01-10 14:11 ` Daniel P. Berrangé
2019-01-10 14:29 ` Yongji Xie
2019-01-10 16:41 ` Daniel P. Berrangé
2019-01-11 7:50 ` Yongji Xie
2019-01-11 8:32 ` Daniel P. Berrangé
2019-01-11 8:36 ` Yongji Xie
2019-01-15 15:39 ` Daniel P. Berrangé
2019-01-15 16:53 ` Yury Kotov
2019-01-15 17:15 ` Daniel P. Berrangé
2019-01-16 5:39 ` Yongji Xie
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 2/7] vhost-user: Support transferring inflight buffer between qemu and backend elohimes
2019-01-14 22:25 ` Michael S. Tsirkin
2019-01-15 6:46 ` Yongji Xie
2019-01-15 12:54 ` Michael S. Tsirkin
2019-01-15 14:18 ` Yongji Xie [this message]
2019-01-18 2:45 ` Yongji Xie
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 3/7] libvhost-user: Introduce vu_queue_map_desc() elohimes
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory elohimes
2019-01-11 3:56 ` Jason Wang
2019-01-11 6:10 ` Yongji Xie
2019-01-15 7:52 ` Jason Wang
2019-01-15 14:51 ` Yongji Xie
2019-01-17 9:57 ` Jason Wang
2019-01-17 14:59 ` Michael S. Tsirkin
2019-01-18 3:57 ` Jason Wang
2019-01-18 3:32 ` Yongji Xie
2019-01-18 3:56 ` Michael S. Tsirkin
2019-01-18 3:59 ` Jason Wang
2019-01-18 4:03 ` Michael S. Tsirkin
2019-01-18 7:01 ` Yongji Xie
2019-01-18 9:26 ` Jason Wang
2019-01-19 12:19 ` Yongji Xie
2019-01-15 15:58 ` Michael S. Tsirkin
2019-01-17 10:01 ` Jason Wang
2019-01-17 15:04 ` Michael S. Tsirkin
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 5/7] vhost-user-blk: Add support to get/set inflight buffer elohimes
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 6/7] vhost-user-blk: Add support to reconnect backend elohimes
2019-01-09 11:27 ` [Qemu-devel] [PATCH v4 for-4.0 7/7] contrib/vhost-user-blk: enable inflight I/O tracking elohimes
2019-01-10 10:25 ` [Qemu-devel] [PATCH v4 for-4.0 0/7] vhost-user-blk: Add support for backend reconnecting Stefan Hajnoczi
2019-01-10 10:59 ` Yongji Xie
2019-01-11 15:53 ` Stefan Hajnoczi
2019-01-11 17:24 ` Michael S. Tsirkin
2019-01-12 4:50 ` Yongji Xie
2019-01-14 10:22 ` Stefan Hajnoczi
2019-01-14 10:55 ` Yongji Xie
2019-01-16 14:28 ` Stefan Hajnoczi
2019-01-10 10:39 ` Marc-André Lureau
2019-01-10 11:09 ` 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=CAONzpcbnGbe-qjZdiBdjrrWbnhCBy+zGTtZ_qOjNoBecC+1r6A@mail.gmail.com \
--to=elohimes@gmail.com \
--cc=berrange@redhat.com \
--cc=chaiwen@baidu.com \
--cc=jasowang@redhat.com \
--cc=lilin24@baidu.com \
--cc=marcandre.lureau@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=nixun@baidu.com \
--cc=qemu-devel@nongnu.org \
--cc=wrfsh@yandex-team.ru \
--cc=xieyongji@baidu.com \
--cc=yury-kotov@yandex-team.ru \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.