Re: [Xen-devel][Pv-ops][PATCH 0/3] Resend: Netback multiple thread support

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Steven Smith <steven.smith@xxxxxxxxxx> 28.04.10 13:51 >>>
>2) Introduce struct ext_page and use it everywhere you use it in the
>   current patch.  This should be fairly small.

In working through the patches to make them usable on our forward
ported trees, I wondered what this is good for at all, for two reasons:

On 64-bits embedding the data directly into page->mapping would
be possible without any other consideration.

Even on 32-bits embedding is possible based on the observation
that the two fields together don't need more than 32 bits (idx
always being less than MAX_PENDING_REQS [which itself could
even grow significantly] and group being bounded by NR_CPUS).

>I think we might be using slightly different terminology here.  When I
>say ``netfront'', I mean the frontend half of a virtual network
>interface, rather than the netfront driver, so a single domain can be
>configured with multiple netfronts in the same way that a single
>physical host can have multiple ixgbes (say), despite only having one
>ixgbe driver loaded.
>
>So, my original point was that it might be better to balance
>interfaces such that the number of interfaces in each group is the
>same, ignoring the frontend domain ID completely.  This would mean
>that if, for instance, a domain had two very busy NICs then they
>wouldn't be forced to share a tasklet, which might otherwise be a
>bottleneck.

As you had pointed out in an earlier reply, the use of the domain
ID here is flawed anyway - it had to be replaced for the whole
set to be usable for us. We count netif-s and balance based on
that count, at once eliminating the need to do any allocation
when adding a new netif.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel