[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] n ways block filters
From: |
Benoît Canet |
Subject: |
Re: [Qemu-devel] n ways block filters |
Date: |
Mon, 17 Mar 2014 14:52:25 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
The Monday 17 Mar 2014 à 11:12:31 (+0800), Fam Zheng wrote :
> On Fri, 03/14 16:57, Benoît Canet wrote:
> >
> > Hello list,
> >
> > I plan to convert throttling to a block filter and write n way throttling
> > support.
> >
> > I discussed a bit with Stefan on the list and we came to the conclusion
> > that the
> > block filter API need group support.
> >
> > filter group:
> > -------------
> >
> > My current plan to implement this is to add the following fields to the
> > BlockDriver
> > structure.
> >
> > int bdrv_add_filter_group(const char *name, QDict options);
> > int bdrv_reconfigure_filter_group(const char *name, QDict options);
> > int bdrv_destroy_filter_group(const char *name);
> >
> > These three extra method would allow to create, reconfigure or destroy a
> > block
> > filter group. A block filter group contain the shared or non shared state
> > of the
> > blockfilter. For throttling it would contains the ThrottleState structure.
> >
> > Each block filter driver would contains a linked list of linked list where
> > the
> > BDS are registered grouped by filter groups state.
>
> Sorry I don't fully understand this. Does a filter group contain multiple
> block
> filters, and every block filter has effect on multiple BDSes? Could you give
> an
> example?
The driver module says block/throttle.c would contains a linked list of
ThrottleGroup
in a static variable.
Each ThrottleGroup would have a name, a ThrottleState (as in utils/throttle.c)
and a linked list of members BDS.
The s variable of the bdrv_* method of throttle.c would have a pointer to the
ThrottleGroup this BDS is a member of hence the driver can access the
ThrottleState
So each BDS filter would have only one BDS parent and one BDS ->file child but
would also be member of a ThrottleGroup.
This would allow to do throttling on a group of devices.
Throttling only one device would create a ThrottleGroup of name bds->device_name
containing only the throttled BDS.
>
> >
> > The regular bdrv_open callback would be used to instantiate a block filter
> > and
> > add it to a filter group. This method would also take a new-node-name for
> > the new
> > filter. This node-name would become the name of the new filter.
> > bdrv_close would cleanup and deregister from a filter group.
> >
> > An extra filter-group field in the option dict would allow the bdrv_open
> > method
> > to register the newly opened block filter in it's filter group.
> > The BDS structure would have a direct pointer to it's filter group state.
> >
> > Utility methods to do the bdrv_add_filter_group bdrv_open then bdrv_swap to
> > install a new filter can be provided by block.c. The same can be done for
> > filter
> > close and desinstallation.
>
> So you are defining block filter as a new kind of block driver. Is a filter
> always on top above everything else by definition?
Yes,
A filter is instanciated on top of another BDS.
Filters can be stacked on top of another to form a chain.
> But I am afraid BlockDriverState is already taking too many responsibilities
> here (backend, protocol driver, format driver, filter...). I was wondering if
> it is clearer to rather introduce bs->filter_list to point to a list of
> BlockFilter (a new sturcture, tailored for a block filter), and don't bother
> with bdrv_swap.
Hmm blkverify and quorum are already block filters reusing the BlockDriver
interface. The good this with this is that it would allow to move some code from
block.c to block/filter_name*.c: block throttling for example.
Crypto would be another use case.
Best regards
Benoît
>
> Thanks,
> Fam
>
> >
> > Legacy throttling QMP API
> > -------------------------
> >
> > The legacy throttling API would create throttling filters groups containing
> > only
> > one BDS.
> >
> > By default for every 1 way block filter block.c would create a filter group
> > using the BDS id or node-name as group name. This allow for easy filer
> > removal
> > with the bds reference.
> >
> > Group throttling API
> > --------------------
> >
> > Commands would be added to create throttling filter groups reconfigure and
> > remove
> > them.
> >
> > Two additional commands would be added to create and insert a block filter
> > in a
> > given group or close and remove it.
> >
> > Before I start implementing something what are your thougths on this ?
> >
> > Best regards
> >
> > Benoît
> >
> >
> >
>
- [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/14
- Re: [Qemu-devel] n ways block filters, Fam Zheng, 2014/03/16
- Re: [Qemu-devel] n ways block filters,
Benoît Canet <=
- Re: [Qemu-devel] n ways block filters, Stefan Hajnoczi, 2014/03/17
- Re: [Qemu-devel] n ways block filters, Kevin Wolf, 2014/03/18
- Re: [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/20
- Re: [Qemu-devel] n ways block filters, Kevin Wolf, 2014/03/20
- Re: [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/20
- Re: [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/20
- Re: [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/24
- Re: [Qemu-devel] n ways block filters, Kevin Wolf, 2014/03/24
- Re: [Qemu-devel] n ways block filters, Benoît Canet, 2014/03/27