[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel][Pv-ops][PATCH 0/3] Resend: Netback multiple thread support
>>> 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |