[ovs-dev] [PATCH V6] netdev-dpdk: Set pmd thread priority

Daniele Di Proietto diproiettod at ovn.org
Thu Aug 18 21:54:15 UTC 2016


2016-08-18 14:20 GMT-07:00 Bodireddy, Bhanuprakash <
bhanuprakash.bodireddy at intel.com>:

> >-----Original Message-----
> >From: Flavio Leitner [mailto:fbl at sysclose.org]
> >Sent: Thursday, August 18, 2016 2:15 PM
> >To: Bodireddy, Bhanuprakash <bhanuprakash.bodireddy at intel.com>
> >Cc: Daniele Di Proietto <diproiettod at ovn.org>; dev at 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:diproiettod at ovn.org]
> >> >Sent: Tuesday, August 16, 2016 1:44 AM
> >> >To: Bodireddy, Bhanuprakash <bhanuprakash.bodireddy at intel.com>
> >> >Cc: dev at openvswitch.org; Flavio Leitner <fbl at 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.


> >
> >
> >> 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?

Thanks,

Daniele


>
> Regards,
> Bhanu Prakash.
>
> >
> >Thanks,
> >--
> >fbl
>
>



More information about the dev mailing list