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@redhat.com> [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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/