On 18 August 2014 19:27, Stuart Haslam <[email protected]> wrote: > On Mon, Aug 18, 2014 at 12:19:49PM +0100, Santosh Shukla wrote: >> On 18 August 2014 16:30, Stuart Haslam <[email protected]> wrote: >> > On Mon, Aug 18, 2014 at 08:41:00AM +0100, Santosh Shukla wrote: > >> > >> > I'm not sure it's worth adding an example application that does nothing. >> > Isolation is not be something the application needs explicit knowledge >> > of so having an example app demonstrating it is a bit odd. All of the >> > existing examples / tests should be capable of being run isolated. >> > >> > For this test you could start with odp_example as it has no dependencies >> >> Not entirely true and I did thought about using odp_example. >> odp_example does use timer api (clock_gettime) which I don't want to >> call from isolated thread. Therefore choose to keep dummy (explicitly >> mentioned in writeup) thread looping for x time. >> > > OK fair enough, so the odp_example would currently fail this test > because there's a problem with the linu-generic implementation of the > timers, this is a known issue and should be fixed at some point.
Keeping known limitation of this approach in mind. I agree :) > >> More appropriate test application is l2fwd, where I am doing isolation. >> > > OK, can you send patches for that instead? :) Yup.. I just finished uploading those patch set to my odp.git repository link [1]. Primarily that git repo made for demo purpose however most of em should go for review/feedback. [1] https://git.linaro.org/people/santosh.shukla/odp.git [P.S: pl. ignore cruel hack done at top most patch, It was for demo. also due design limitation in existing global_init_dpdk() function.. Its one of use-case for "global_init" generic argument passing discussion happened last week, Assuming that Mikey working on it so didn't paid much attention.] > >> There is a readme (in next patch) which very much informs NOT to use >> odp method of cpuset for thread pinning instead use script. > > Yeah I read that - it doesn't say why not though. Hmm.. I 'll make it more clear in readme -:) > >> I could >> choose to add job enqueue/dequeue in while loop But in next patch. > > I don't think that's the right direction to head. Given that any of the > tests or examples should be capable of running isolated, if we were to > have a specific isolation test then it would just end up replicating all > of the other tests. It would be better to just run the existing tests > on isolated cores. As you say that's not possible at the minute, but it > should be a goal - and the easiest way to start is by picking an > existing test that does work on isolated cores. > Fair enough. dpdk-s-port-for-odp-l2fwd works!! My scope of work to make one *existing* application demoable for no_hz_full isolation. As you said, Yes we should target and introduce isolation specific hints in framework to make other application work seamlessly. >> > >> > I wonder if changing odp_linux_pthread_create to take an array of cores >> > rather than just the first core is a better way to go. A quick grep >> > through the existing examples / tests shows almost all callers provide 1 >> > for the number of cores, so it's not currently being used as expected. >> > >> >> Nope. Not in this case, I want to create thread on any of cores based >> on arg_list, That may be look like this - >> -l 2,3,5,6 OR -l 3,5,6,7 >> >> Also changing the order helps me to test my isolation script. >> > > Yes, what I was suggesting would make that easier. Instead of looping > over num_workers and setting first_core and num for each iteration you > just pass in an array of core numbers that you want threads started on, > e.g.; > > odp_linux_pthread_create(thread_tbl, num_workers, args.core_num, > run_thread, NULL); > > Where args.core_num is just what you currently have as args.core_name > but stored as an integer. > even better. Sorry for confusion. In summary, Does it make sense to keep this dummy app alive in odp? As I iterated that Its very handy app for me to test randomize order for "any core number pinning to any thread" and In future, there might be possibility [Which Ola mentioned in RT vs Isolation discussion last week] of one core two threads or many threads. In such case, It make sense to me to keep this app alive and keep maturing it will combination of use-cases like 1 cpu :: 2 Threads etc.. Again a test example for isolation but much handy to test.. no setup dependency like l2fwd etc.. > -- > Stuart. > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
