qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4 for-4.0 4/7] libvhost-user: Support tracking inflight I/O in shared memory
Date: Thu, 17 Jan 2019 10:04:28 -0500

On Thu, Jan 17, 2019 at 06:01:16PM +0800, Jason Wang wrote:
> 
> On 2019/1/15 下午11:58, Michael S. Tsirkin wrote:
> > On Tue, Jan 15, 2019 at 03:52:21PM +0800, Jason Wang wrote:
> > > Well, this may work but here're my points:
> > > 
> > > 1) The code want to recover from backed crash by introducing extra space 
> > > to
> > > store inflight data, but it still depends on the backend to set/get the
> > > inflight state
> > > 
> > > 2) Since the backend could be killed at any time, the backend must have 
> > > the
> > > ability to recover from the partial inflight state
> > > 
> > > So it looks to me 1) tends to be self-contradictory and 2) tends to be
> > > recursive. The above lines show how tricky could the code looks like.
> > This is a well studied field. Basically you make sure you commit with an
> > atomic write.  Restartable sequences allow accelerating this even
> > further.
> 
> 
> I'm not sure I get this. But the issue is to exactly deduce all the inflight
> descriptors even if backend could be killed when doing the logging. If we
> could not be 100% accurate, it's have much less value.


I agree. But why discuss theoretical issues?
Can you point out a problem in the contrib/ code
included here?

If yes it must be fixed I think.

I personally think it's not too hard.
Consider packed ring for example - just maintain a list of the inflight
descriptors, as the last step write out the flags atomically.




> 
> > 
> > > Solving this at vhost-user level through at backend is probably wrong. 
> > > It's
> > > time to consider the support from virtio itself.
> > > 
> > > Thanks
> > I think both approaches have their space.
> 
> 
> But there will be a lot of duplicated work if we decide to support it from
> virtio.
> 
> Thanks
> 
> 
> > 
> > -- MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]