Xen devel - Mar 2012 - xl: Need help with overflow and error handling for vif rate support

Hi,

I''m working a patch to add support for vif rate limiting support to 
libxl/xl. [1]

I''m especially working on using uint64_t instead of uint32_t [2] and 
adding error handling. [3]

- How should I check for overflows when multiplying 2 uint64_t together?
   - I''m currently using math.h and log. Is it the correct approach?
- How should I handle errors?
   - Should I do something similar to libxlu_disk.c?
   - Should xlu_vif_parse_rate prints an error and returns an error code?
   - If the error is from one of the "helpers", should they print an 
error too or should xlu_vif_parse_rate deals with it?

Any help would be greatly appreciated.

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01596.html
[2] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01627.html
[3] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01738.html

-- 
Mathieu

On Tue, 2012-03-27 at 18:04 +0100, Mathieu Gagné wrote:
> Hi,
> 
> I'm working a patch to add support for vif rate limiting support to 
> libxl/xl. [1]
> 
> I'm especially working on using uint64_t instead of uint32_t [2] and 
> adding error handling. [3]
> 
> - How should I check for overflows when multiplying 2 uint64_t together?
>    - I'm currently using math.h and log. Is it the correct approach?
You can check if A*B > UINT64_MAX by first checking
	if B != 0 && A > UINT64_MAX/B
		WOULD OVERFLOW

Assuming we are talking about rate_interval_usecs and
rate_bytes_per_interval then rate_interval_usecs can probably be a 32
bit number, UINT32_MAX usecs is something like 71 minutes, which ought
to be plenty. Only rate_bytes_per_interval rally needs to be a 64 bit
value.
> - How should I handle errors?
>    - Should I do something similar to libxlu_disk.c?
>    - Should xlu_vif_parse_rate prints an error and returns an error code?
Yes, I think so. Return an appropriate error code for each failure
(EINVAL, EOVERFLOW etc)
>    - If the error is from one of the "helpers", should they print
an
> error too or should xlu_vif_parse_rate deals with it?
Either is fine so long as a message is printed exactly once in the case
of an error. If you can give more specific messages in the helpers then
it likely makes sense to do it there.
> 
> Any help would be greatly appreciated.
> 
> Regards,
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01596.html
> [2] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01627.html
> [3] http://lists.xen.org/archives/html/xen-devel/2012-03/msg01738.html
> 



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

Ian Campbell writes ("Re: [Xen-devel] xl: Need help with overflow and error
handling for vif rate support"):
> On Tue, 2012-03-27 at 18:04 +0100, Mathieu Gagné wrote:
> > - How should I check for overflows when multiplying 2 uint64_t
together?
> >    - I''m currently using math.h and log. Is it the correct
approach?
> 
> You can check if A*B > UINT64_MAX by first checking
> 	if B != 0 && A > UINT64_MAX/B
> 		WOULD OVERFLOW
Another approach is to limit both A and B to less than
sqrt(UINT64_MAX), or to limit each of them to some smaller number.

Or use floating point, and do a check at the end when you convert it
back.

Ian.

On Thu, 2012-03-29 at 15:36 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] xl: Need help with overflow and
error handling for vif rate support"):
> > On Tue, 2012-03-27 at 18:04 +0100, Mathieu Gagné wrote:
> > > - How should I check for overflows when multiplying 2 uint64_t
together?
> > >    - I'm currently using math.h and log. Is it the correct
approach?
> > 
> > You can check if A*B > UINT64_MAX by first checking
> > 	if B != 0 && A > UINT64_MAX/B
> > 		WOULD OVERFLOW
> 
> Another approach is to limit both A and B to less than
> sqrt(UINT64_MAX), or to limit each of them to some smaller number.
I looked at that, you can limit the interval ok to even less than that
but the rate would ideally have the possibility to be bigger than this
would allow.

I ran some vague numbers using 1s as the max interval and the rate was
in the several 10s of gigabytes, which is a lot today but not very
future proof...
> 
> Or use floating point, and do a check at the end when you convert it
> back.
> 
> Ian.


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