Radu Can you join the opencall today to discuss this ? http://www.uberconference.com/opendataplane 4.00pm GMT
Mike On 25 May 2015 at 04:37, Radu-Andrei Bulie <[email protected]> wrote: > Hi, > > > > The patch mentioned in the title is somehow related with the idea of odp > threads isolation, I mean the odp data path threads. > > I am not aware of any discussions regarding the cgroups to provide odp > threads isolation nor some updates in the odp > > API that will provide an integration with the cgroup library and cpusets > usage. > > As it is stated in the ODP documentation the odp data path threads are not > controlled by the Linux scheduler - instead there is > > a HW SoC level scheduler that manages them (or a specialized SW). This > implies that there is not any strict dependency in isolating the odp > threads by the rest > > of the linux processes. > > The problem introduced by this patch, on our platform, is that it > restricts the usage of all cores available on the default scheduling domain > provided by Linux. > > And when I say all cores I include here the cores which are isolated from > rest and do not participate in the load balancing scheme of the > scheduler.(this is achieved > > with the kernel boot time isolcpus). This cores will be used for the odp > data path threads and will be assigned explicitly at threads' creation time. > > Thus the Linux scheduler will load balance processes(threads) on the > non-isolated cores.(these will be the odp control path threads). > > The exact problem of the patch is that - to determine the number of cores > available for threads' creation - it uses the pthread_getaffinity_np > function (and not > > _SC_NPROCESSORS_ONLN as before) which will return all the cores on which a > threads is eligible to run - that is all the cores that participate in the > Linux > > load balancing scheme. In this situation(with this patch), on our > platform, we are able to create, for example, just one thread - on core 0, > which is used for control, because > > the other cores 1..n which are isolated, are not visible using the > function mentioned above.(and as I said they will be used for the fast path > processing) > > As a conclusion, an action should be taken regarding the mentioned patch. > > > > > > Regards, > > > > Radu > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
