Re: [Xen-devel] [PATCH 0 of 9 RFC v2] blktap3: Introduce a small subset of blktap3 files

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-01-18 at 16:37 +0000, Thanos Makatos wrote:
> > > 4. tapback: a user space daemon that acts as the back-end of each
> > virtual
> > >    block device: it monitors XenStore for the block front-end's state
> > changes,
> > >    creates/destroys the shared ring, and instructs the tapdisk to
> > connect
> > >    to/disconnect from the shared ring. It also communicates to the
> > block
> > >    front-end required parameters (e.g. block device size in sectors)
> > via
> > >    XenStore.
> > 
> > There is 1 tapdisk per VBD but how many tapbacks are there? One per VBD
> > as well or one per domain or per driver domain?
> 
> There is one tapback daemon in total, serving all VBDs/domains.

You mean one per backend domain I assume?

> The tapback daemon sets a XenStore watch to "backend/<device type>" to
> serve VBD creations for completely new domains, and then sets an
> additional watch to the front-end state path for each VBD. I guess
> there could be one tapback daemon detecting completely new domains,
> responsible for spawning tapback daemons designated to a specific
> domain/VBD. I'm not sure of the implications of this approach, though.
> (We could also have one thread designated to each domain/VBD.) Is
> there a particular reason why a single tapback daemon wouldn't
> suffice?

No, it sounds reasonable. I was more concerned there might be one per
VBD in which case it would have made sense to merge tapdisk and tapback.

> > Is tapback involved in things after the ring has been setup and it has
> > instructed tapdisk to use it? i.e. is it on the datapath at all?
> 
> The tapback daemon is involved only for running the Xenbus protocol
> when the front-end is set up/torn down -- no participation in the data
> path.

Oh good.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel