Re: [Qemu-block] [PATCH v13 2/6] qmp: Use ThrottleLimits structure
On 10/13/2017 4:26 PM, Eric Blake wrote:
[adding Markus, and block list]
On 10/13/2017 09:16 AM, Alberto Garcia wrote:
On Mon 02 Oct 2017 04:33:28 PM CEST, Pradeep Jagadeesh wrote:
This patch factors out code to use the ThrottleLimits
structure.
{ 'struct': 'BlockIOThrottle',
- 'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd': 'int',
-'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
-'*bps_max': 'int', '*bps_rd_max': 'int',
-'*bps_wr_max': 'int', '*iops_max': 'int',
-'*iops_rd_max': 'int', '*iops_wr_max': 'int',
-'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
-'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
-'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
-'*iops_size': 'int', '*group': 'str' } }
+ 'base': 'ThrottleLimits',
+ 'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }
So BlockIOThrottle used to have parameters named bps_rd and iops_wr, and
after this patch they become bps-read and iops-write. This breaks the
API completely, as you can see if you run e.g. iotest 129:
AssertionError: failed path traversal for "return" in "{u'error': {u'class': u'GenericError',
u'desc': u"Parameter 'iops_rd' is unexpected"}}"
I just checked previous versions of the series and I see that Manos
already warned you of this in v11:
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04698.html
On the bright side, ThrottleLimits is marked 'since 2.11' (added in
commit 432d889e), meaning it has not yet been released, so we CAN fix
the naming in ThrottleLimits to be compatible with BlockIOThrottle if we
want to share the type, as long as we get it done before the 2.11
release. It does mean tweaking Manos' code to use compatible names
everywhere, but that may be a wise course of action (we tend to favor
'-' in new API names unless there is a strong reason to use '_'; but
sharing code for maximum back-compat would be a reason to use '_').
Could you please have a look at Manos reply and my reply also.
Please let me know what you think.
-Pradeep
Re: [Qemu-block] [PATCH v13 2/6] qmp: Use ThrottleLimits structure
On 11/6/2017 10:35 AM, Manos Pitsidianakis wrote:
On Fri, Oct 13, 2017 at 09:26:17AM -0500, Eric Blake wrote:
[adding Markus, and block list]
On 10/13/2017 09:16 AM, Alberto Garcia wrote:
On Mon 02 Oct 2017 04:33:28 PM CEST, Pradeep Jagadeesh wrote:
This patch factors out code to use the ThrottleLimits
structure.
{ 'struct': 'BlockIOThrottle',
- 'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd':
'int',
-'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int',
'iops_wr': 'int',
-'*bps_max': 'int', '*bps_rd_max': 'int',
-'*bps_wr_max': 'int', '*iops_max': 'int',
-'*iops_rd_max': 'int', '*iops_wr_max': 'int',
-'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
-'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
-'*iops_rd_max_length': 'int', '*iops_wr_max_length':
'int',
-'*iops_size': 'int', '*group': 'str' } }
+ 'base': 'ThrottleLimits',
+ 'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }
So BlockIOThrottle used to have parameters named bps_rd and iops_wr, and
after this patch they become bps-read and iops-write. This breaks the
API completely, as you can see if you run e.g. iotest 129:
AssertionError: failed path traversal for "return" in "{u'error':
{u'class': u'GenericError', u'desc': u"Parameter 'iops_rd' is
unexpected"}}"
I just checked previous versions of the series and I see that Manos
already warned you of this in v11:
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04698.html
On the bright side, ThrottleLimits is marked 'since 2.11' (added in
commit 432d889e), meaning it has not yet been released, so we CAN fix
the naming in ThrottleLimits to be compatible with BlockIOThrottle if we
want to share the type, as long as we get it done before the 2.11
release.
We decided to keep BlockIOThrottle separate from ThrottleLimits because
that would break the old I/O throttling API, just like is done in this
patch series. BlockIOThrottle is the one using old naming conventions
so I think it should be the one to go, if that has to be done.
But this all boils down to whether the legacy throttling API has to
break in 2.11 or not, which probably is the maintainer's decision.
It does mean tweaking Manos' code to use compatible names
everywhere, but that may be a wise course of action (we tend to favor
'-' in new API names unless there is a strong reason to use '_'; but
sharing code for maximum back-compat would be a reason to use '_').
Thanks for your reply Manos.
@Eric, So shall I go ahead and revert my patches to as before. I mean
using iothrottle structure?.
What is your suggestion?
-Pradeep
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [Qemu-block] [PATCH v13 2/6] qmp: Use ThrottleLimits structure
Hi Manos,
Could you please have a look at Eric's comments.
Regards,
Pradeep
On 10/13/2017 4:26 PM, Eric Blake wrote:
[adding Markus, and block list]
On 10/13/2017 09:16 AM, Alberto Garcia wrote:
On Mon 02 Oct 2017 04:33:28 PM CEST, Pradeep Jagadeesh wrote:
This patch factors out code to use the ThrottleLimits
structure.
{ 'struct': 'BlockIOThrottle',
- 'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd': 'int',
-'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
-'*bps_max': 'int', '*bps_rd_max': 'int',
-'*bps_wr_max': 'int', '*iops_max': 'int',
-'*iops_rd_max': 'int', '*iops_wr_max': 'int',
-'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
-'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
-'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
-'*iops_size': 'int', '*group': 'str' } }
+ 'base': 'ThrottleLimits',
+ 'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }
So BlockIOThrottle used to have parameters named bps_rd and iops_wr, and
after this patch they become bps-read and iops-write. This breaks the
API completely, as you can see if you run e.g. iotest 129:
AssertionError: failed path traversal for "return" in "{u'error': {u'class': u'GenericError',
u'desc': u"Parameter 'iops_rd' is unexpected"}}"
I just checked previous versions of the series and I see that Manos
already warned you of this in v11:
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04698.html
On the bright side, ThrottleLimits is marked 'since 2.11' (added in
commit 432d889e), meaning it has not yet been released, so we CAN fix
the naming in ThrottleLimits to be compatible with BlockIOThrottle if we
want to share the type, as long as we get it done before the 2.11
release. It does mean tweaking Manos' code to use compatible names
everywhere, but that may be a wise course of action (we tend to favor
'-' in new API names unless there is a strong reason to use '_'; but
sharing code for maximum back-compat would be a reason to use '_').
Re: [Qemu-block] [PATCH v13 2/6] qmp: Use ThrottleLimits structure
On 10/13/2017 4:26 PM, Eric Blake wrote:
[adding Markus, and block list]
On 10/13/2017 09:16 AM, Alberto Garcia wrote:
On Mon 02 Oct 2017 04:33:28 PM CEST, Pradeep Jagadeesh wrote:
This patch factors out code to use the ThrottleLimits
structure.
{ 'struct': 'BlockIOThrottle',
- 'data': { '*device': 'str', '*id': 'str', 'bps': 'int', 'bps_rd': 'int',
-'bps_wr': 'int', 'iops': 'int', 'iops_rd': 'int', 'iops_wr': 'int',
-'*bps_max': 'int', '*bps_rd_max': 'int',
-'*bps_wr_max': 'int', '*iops_max': 'int',
-'*iops_rd_max': 'int', '*iops_wr_max': 'int',
-'*bps_max_length': 'int', '*bps_rd_max_length': 'int',
-'*bps_wr_max_length': 'int', '*iops_max_length': 'int',
-'*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
-'*iops_size': 'int', '*group': 'str' } }
+ 'base': 'ThrottleLimits',
+ 'data': { '*device': 'str', '*id': 'str', '*group': 'str' } }
So BlockIOThrottle used to have parameters named bps_rd and iops_wr, and
after this patch they become bps-read and iops-write. This breaks the
API completely, as you can see if you run e.g. iotest 129:
AssertionError: failed path traversal for "return" in "{u'error': {u'class': u'GenericError',
u'desc': u"Parameter 'iops_rd' is unexpected"}}"
I just checked previous versions of the series and I see that Manos
already warned you of this in v11:
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04698.html
On the bright side, ThrottleLimits is marked 'since 2.11' (added in
commit 432d889e), meaning it has not yet been released, so we CAN fix
the naming in ThrottleLimits to be compatible with BlockIOThrottle if we
want to share the type, as long as we get it done before the 2.11
release. It does mean tweaking Manos' code to use compatible names
everywhere, but that may be a wise course of action (we tend to favor
'-' in new API names unless there is a strong reason to use '_'; but
sharing code for maximum back-compat would be a reason to use '_').
Sorry for the late reply. I was out of office.
I am ready to change them to "_" instead of "-".
Need to ask Manos.
@Manos, what do you say about the above comment. That makes sense.
It will help to reuse lot of code. Shall we rename the parameters with
"_" instead of "-"?
Regards,
Pradeep
Re: [Qemu-block] [PATCH v10 0/6] fsdev: qmp interface for io throttling
On 9/5/2017 11:19 PM, Eric Blake wrote: On 09/04/2017 11:07 AM, Pradeep Jagadeesh wrote: These patches provide the qmp interface, to query the io throttle status of the all fsdev devices that are present in a vm. also, it provides an interface to set the io throttle parameters of a fsdev to a required value. some of the patches also remove the duplicate code that was present in block and fsdev files. Pradeep Jagadeesh (6): throttle: factor out duplicate code qmp: Create IOThrottle structure throttle: move out function to reuse the code hmp: create a throttle initialization function for code reusability fsdev: QMP interface for throttling fsdev: hmp interface for throttling I know you're already up to v10, but your code changes conflict with Manos throttling work, which has now landed on Kevin's branch: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg01051.html T: git git://repo.or.cz/qemu/kevin.git block How hard is it for you to post a rebased v11 on top of Manos' work? Hmm, I will try. No idea, how long its gonna take. -Pradeep
