Re: [Xen-devel] Volunteers required for 4.2 TODO items (Re: 4.2 TODO update)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-03-12 at 16:00 +0000, Mathieu Gagnà wrote:
> On 3/12/12 8:22 AM, Ian Campbell wrote:
> > On Mon, 2012-03-12 at 12:11 +0000, Ian Campbell wrote:
> >> There are several things below which are in need of a volunteer to take 
> >> care of them...
> >
> > Specifically:
> >
> >> tools, nice to have:
> >>        * support for vif "rate" parameter (No one, AFAICT)
> >
> 
> I'm working on a patch to add support for vif rate limiting in libxl.
> 
> I don't have much experience with C and my knowledge is limited. 
> (although I develop in other languages)
> 
> At this moment, I only have a "proof of concept" with a main function so 
> I can play and do tests to verify the parsing/results. 
> (bytes_per_interval,interval_usecs)
> 
> I would have a couple of questions about how to integrate the 
> feature/code within libxl/xl.
> 
> The rate syntax

Are you copying the xm/xend syntax here?

>  requires relatively complex parsing which would require 
> at least 3 new functions which could all be combined in one if required. 
> (parse_vif_rate, parse_vif_rate_bytes_per_sec

Aren't these the same function but with handling for units?

> and parse_vif_rate_interval_usecs)

I think externally a single function to parse a rate and initialise the
relevant fields of libxl_device_nic is the way to go. Perhaps internal
to the implementation of that there might be additional helpers etc.

> Where should those functions be added? xl_cmdimpl.c?

How about libxlu_vif.c (new file, similar to e.g. libxlu_disk.c)? libxlu
is a library of stuff which is part of xl which might be useful to other
toolstacks -- code for parsing vif rate's seems to fall into that
category, much like parsing disk configure strings does.

> What should be the names of the new struct members of libxl_device_nic? 
> I same some "suggestions" in the previous rejected patch [1]. Are those 
> names good? Should they be closer to the concept of "rate" instead of "qos"?

I suppose it depends what their actual semantics are. Something like
max_<unit>_per_<thing> and <thing>_per_second/<thing>_<time-unit> should
be ok I guess?

> Also, should more information be provided to the user about the rate 
> syntax? rate=<rate> isn't that useful.

The new option/syntax should be fully documented in
docs/misc/xl-network-configuration.markdown which is referenced by
docs/man/xl.cfg.pod.5.

> Thanks!

Thanks for doing this -- looking forward to the patches!

Ian.



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