> >2016-08-18 14:20 GMT-07:00 Bodireddy, Bhanuprakash ><bhanuprakash.bodire...@intel.com>: >>-----Original Message----- >>From: Flavio Leitner [mailto:f...@sysclose.org] >>Sent: Thursday, August 18, 2016 2:15 PM >>To: Bodireddy, Bhanuprakash <bhanuprakash.bodire...@intel.com> >>Cc: Daniele Di Proietto <diproiet...@ovn.org>; dev@openvswitch.org >>Subject: Re: [ovs-dev] [PATCH V6] netdev-dpdk: Set pmd thread priority >> >>On Tue, Aug 16, 2016 at 02:30:04PM +0000, Bodireddy, Bhanuprakash wrote: >>> >-----Original Message----- >>> >From: Daniele Di Proietto [mailto:diproiet...@ovn.org] >>> >Sent: Tuesday, August 16, 2016 1:44 AM >>> >To: Bodireddy, Bhanuprakash <bhanuprakash.bodire...@intel.com> >>> >Cc: dev@openvswitch.org; Flavio Leitner <f...@sysclose.org> >>> >Subject: Re: [PATCH V6] netdev-dpdk: Set pmd thread priority >>> > >>> >I found a crash if apply this patch, "dpdk-lcore-mask" is not set and >>> >"-c 0x1" is passed to "dpdk-extra". >>> My bad, I didn't test with dpdk-extra options. I see that the crash was due >to >>strtol. >>> >>> >Also, I believe Flavio had a comment on the previous version of this >>> >patch. Would it be enough to use setpriority(2)? >>> I sent out my comments in another mail. I agree to Flavio's suggestion >>> as this seems less dangerous and is guaranteed to work even in case of >>> misconfiguration. I tested this approach and have a concern with >>setpriority(). >>> >>> To apply the new nice value to the thread, thread id is needed and due >>> to absence of glibc wrapper for gettid, I have to use syscall(SYS_gettid). I >>want to know if this is acceptable in OVS or better way to handle this? >>> >>> Void ovs_numa_thread_setpriority(int nice OVS_UNUSED) { .... >>> #if defined(__linux__) && defined(SYS_gettid) >>> pid_t tid = syscall(SYS_gettid); >>> err = setpriority(PRIO_PROCESS, tid, nice); >>> .... >>> #endif >>> } >> >>I don't know a better way to implement this and it seems ovs-numa.c >already >>has some ifdefs specific to linux. >> >>Do you know if this problem happen on BSD? >I don't know if this is a problem on BSD. I searched a bit and found BSD code >using "syscall(SYS_thr_self, &tid)" >to retrieve the tid. > > >The dummy ovs-numa works (and thus compile) everywhere, for pmd tests, >but the module only works on linux. >I think it's fine to implement something only for linux and return >EOPNOTSUPP (only if dummy is not enabled) for everything else. > >I think passing 0 as thread_id to setpriority() changes the current thread >priority, so there's probably no need for SYS_gettid.
This is helpful, passing 0 for thread_id worked. > >> >> >>> Without priority patch: >>> >>> $ ps -eLo tid,pri,psr,comm | grep -e lcore -e revalidator -e ovs-vswitchd -e >>pmd >>> 22509 19 4 ovs-vswitchd >>> 22512 19 5 lcore-slave-5 >>> 22513 19 6 lcore-slave-6 >>> 22514 19 7 lcore-slave-7 >>> 22589 19 4 revalidator37 >>> 22590 19 4 revalidator52 >>> 22591 19 4 revalidator42 >>> 22592 19 4 revalidator38 >>> 22593 19 4 revalidator39 >>> 22594 19 4 revalidator45 >>> 22595 19 4 revalidator53 >>> 22596 19 4 revalidator54 >>> 22598 19 4 pmd61 [Default priority] >>> >>> With priority patch: >>> >>> $ ps -eLo tid,pri,psr,comm | grep -e lcore -e revalidator -e ovs-vswitchd -e >>pmd >>> 24879 19 4 ovs-vswitchd >>> 24881 19 5 lcore-slave-5 >>> 24882 19 6 lcore-slave-6 >>> 24883 19 7 lcore-slave-7 >>> 24951 19 4 revalidator55 >>> 24952 19 4 revalidator37 >>> 24953 19 4 revalidator52 >>> 24954 19 4 revalidator42 >>> 24955 19 4 revalidator38 >>> 24956 19 4 revalidator39 >>> 24957 19 4 revalidator45 >>> 24958 19 4 revalidator53 >>> 24964 39 4 pmd61 [Higher priority set] >> >>Looks good, so if you affinity your bash to the CPU running >>pmd61 thread, are you able to use it? >Yes, I tested this case and there seems to be no problem here. > >So there's no need to make it exclusive with dpdk-lcore-mask anymore, right? Yes, I have sent out another version of patch which doesn't change any of the existing functionality but lower the nice Value of the pmd thread to -20. Regards, Bhanu Prakash. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
