From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:56366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjIUz-0004wJ-4k for qemu-devel@nongnu.org; Tue, 15 Jan 2019 01:46:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjIUy-00045g-9B for qemu-devel@nongnu.org; Tue, 15 Jan 2019 01:46:57 -0500 Received: from mail-yw1-xc43.google.com ([2607:f8b0:4864:20::c43]:40411) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gjIUy-00043z-3n for qemu-devel@nongnu.org; Tue, 15 Jan 2019 01:46:56 -0500 Received: by mail-yw1-xc43.google.com with SMTP id g194so652784ywe.7 for ; Mon, 14 Jan 2019 22:46:56 -0800 (PST) MIME-Version: 1.0 References: <20190109112728.9214-1-xieyongji@baidu.com> <20190109112728.9214-3-xieyongji@baidu.com> <20190114172157-mutt-send-email-mst@kernel.org> In-Reply-To: <20190114172157-mutt-send-email-mst@kernel.org> From: Yongji Xie Date: Tue, 15 Jan 2019 14:46:42 +0800 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH v4 for-4.0 2/7] vhost-user: Support transferring inflight buffer between qemu and backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , Jason Wang , "Coquelin, Maxime" , Yury Kotov , =?UTF-8?B?0JXQstCz0LXQvdC40Lkg0K/QutC+0LLQu9C10LI=?= , qemu-devel , zhangyu31@baidu.com, chaiwen@baidu.com, nixun@baidu.com, lilin24@baidu.com, Xie Yongji On Tue, 15 Jan 2019 at 06:25, Michael S. Tsirkin 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? > > > 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