On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
> Daniel Veillard wrote:
>
> >On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
> >
> >
> >>* Daniel Veillard <veillard@xxxxxxxxxx> [2007-10-11 08:01]:
> >>
> >>
> >>> - for the mapping at the XML level I suggest to use a simple extension
> >>> to the <vcpu>n</vcpu> and extend it to
> >>> <vcpu cpuset='2,3'>n</vcpu>
> >>> with a limited syntax which is just the comma separated list of
> >>> allowed CPU numbers (if the code actually detects such a cpuset is
> >>> in effect i.e. in general this won't be added).
> >>>
> >>>
> >>I think we should support the same cpuset notation that Xen supports,
> >>which means including ranges (1-4) and negation (^1). These two
> >>features make describing large ranges much more compact.
> >>
> >>
> >
> > Enclosed is a rewrite of the cpuset notations, which can plug as
> >a replacement for the current code in xend_internals, it should support
> >the existing syntax currently used to parse xend topology strings,
> >and also alllow ranges and negation. It's not as a patch but as a
> >standlone replacement program which can be used to test (in spirit
> >of the old topology.c one from Beth).
> > I guess that's okay, check the test output (and possibly extend the
> >test cases in tests array), It tried to think of everything including
> >the weird \\n python xend bug and the 'no cpus' in cell cases.
> >Just dump tst.c in libvirt/src, add $(INCLUDES) to the
> >$(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run
> >make tst
> >./tst
> >and check the output (also enclosed),
> > The parsing is done in a slightly different way, but that should
> >not change the output,
> >
> >Daniel
> >
> >
> >
> >
> >
> ...
>
> >------------------------------------------------------------------------
> > cur = str;
> > while (*cur != 0) {
> > /*
> > * Find the next NUMA cell described in the xend output
> > */
> > cur = strstr(cur, "node");
> > if (cur == NULL)
> > break;
> > cur += 4;
> > cell = parseCpuNumber(&cur, maxcpu);
> >
> >
> This is certainly a nit, but I might change parseCpuNumber to
> parseNumber, since it looks a little odd that you are getting the cell
> id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu,
which doesn't make that much sense. Since we are testing against
maxcpu I really think we should keep the function name, I can
duplicate code and make a simpler function just for parsing the
cell no.
> > if (cell < 0)
> > goto parse_error;
> > skipSpaces(&cur);
> > if (*cur != ':')
> > goto parse_error;
> > cur++;
> > skipSpaces(&cur);
> > if (!strncmp (cur, "no cpus", 7)) {
> > nb_cpus = 0;
> > for (cpu = 0;cpu < maxcpu;cpu++)
> > cpuset[cpu] = 0;
> > } else {
> > nb_cpus = parseCpuSet(conn, &cur, 'n', cpuset, maxcpu);
> >
> >
> Other than our discussion on #virt about handling of ^N specifications
> in parseCpuSet, looks good!
Which is done in my version, will propagate.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list