We have the same kind of "issue" with our port.
We don't want (more precisely cannot for the moment) more than a thread per 
core.

The way we handled it is by tweaking the implementation of cpu_count and the 
default_mask to ignore the first core (which is running the main).

It would make sense to have a more "standard" way of expressing this than 
hacking the cpu_count per platform/test.


On 06/29/2015 05:59 PM, Maxim Uvarov wrote:
> Radu-Andrei,
>
> we also needed to limit number of workers for dpdk:
> https://lists.linaro.org/pipermail/lng-odp-dpdk/2015-June/000844.html
>
> I will send this patch to main mailing list.
>
> Maxim.
>
> On 06/29/15 17:44, Bill Fischofer wrote:
>> This is timely.  I'll add it to the agenda for tomorrow's ODP call.
>>
>> On Mon, Jun 29, 2015 at 9:43 AM, Radu-Andrei Bulie <radu.bu...@freescale.com 
>> <mailto:radu.bu...@freescale.com>> wrote:
>>
>>     Hi,
>>
>>     There are two items I would like to discuss:
>>
>>     1.I have sent an email regarding the schedule tests issues (this
>>     could be a general issue)
>>
>>     To relieve from a search on the mailing list I will paste the
>>     content (and make a resumee):
>>
>>     “I have some observations regarding the odp_scheduler test
>>     functionality.
>>
>>     Scheduler validation  creates two kind of tests:
>>
>>     -single threaded tests – that uses the cunit main thread for
>>     initialization.
>>
>>     -multithreaded tests – that create a number of threads equal with
>>     the number of cores in the system.
>>
>>     As I said in an older post (regarding the classification tests)
>>     there could be a problem on some platforms when the schedule
>>     function is called
>>
>>     on a core that is used by linux(that is –schedule cannot be call
>>     on any core).  This issue could happen on both kind of tests.
>>
>>     The same approach as in the main applications should be applied
>>     regarding tests (e.g core 0 is for linux and the other for odp
>>     threads)
>>
>>     Another possible problem is that the tests use a *while(1)* – and
>>     cycle until all the expected packets are received on the scheduled
>>     queues.
>>
>>     That means that the queues will be scheduled on each of the cores
>>     where the odp_threads were created. I think that there is no
>>     guarantee on this and there is a possibility
>>
>>     that some of the threads will remain in the *while(1) –(queues
>>     will not be scheduled on those cores where the threads were
>>     running, the number of expected frames is not reached) *and thus
>>     the tests will hang.”
>>
>>     Shortly said – the multithreaded tests from schedule create a
>>     number of worker threads equal with the number of cores in the
>>     system ( thus running one of the worker threads on the control
>>     core. As I said(in previous emails),  this could be a problem –
>>     because the tests do not respect the model with a control core,
>>     and data path cores.
>>
>>     In this case,  on our platform,  the multithreaded tests fail
>>     (they hang- because nothing will be scheduled on the control core,
>>     and as I said in the email
>>
>>     there is a while loop that cycles until a number of packets is
>>     reached). Is there any intention to fix this?
>>
>>     2.We made an internal patch on the cunit common sources so that we
>>     are able to run individual tests from a validation suite.
>>
>>     For example, for  odp_pktio validation test – it could be run only
>>     – “pktio poll queues” test. Generally a user will be able to run
>>     one or multiple tests
>>
>>     from a validation test (thus validating only those components in
>>     which he is interested). I want to know if this could be
>>     considered a useful modification and if the answer was
>>     affirmative, we would push the patch to the list.
>>
>>     Regards,
>>
>>     Radu
>>
>>
>>     _______________________________________________
>>     lng-odp mailing list
>>     lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>
>>     https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp

_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to