Hello Flavio, Thanks for your feedback, unfortunately I missed this mail due to my outlook filter settings. Please see my comments inline.
>-----Original Message----- >From: Flavio Leitner [mailto:f...@sysclose.org] >Sent: Thursday, July 28, 2016 8:27 PM >To: Bodireddy, Bhanuprakash <bhanuprakash.bodire...@intel.com> >Cc: Daniele Di Proietto <diproiet...@ovn.org>; Kavanagh, Mark B ><mark.b.kavan...@intel.com>; dev@openvswitch.org >Subject: Re: [ovs-dev] [PATCH v5] netdev-dpdk: Set pmd thread priority > >On Thu, Jul 28, 2016 at 03:39:58PM +0000, Bodireddy, Bhanuprakash wrote: >> >-----Original Message----- >> >From: Daniele Di Proietto [mailto:diproiet...@ovn.org] >> >Sent: Wednesday, July 27, 2016 10:10 PM >> >To: Kavanagh, Mark B <mark.b.kavan...@intel.com> >> >Cc: Bodireddy, Bhanuprakash <bhanuprakash.bodire...@intel.com>; >> >dev@openvswitch.org >> >Subject: Re: [PATCH v5] netdev-dpdk: Set pmd thread priority >> > >> >Thanks for the patch, the implementation looks good to me too. >> >During testing I kept noticing that it's way too easy to make OVS >> >completely unresponsive. As you point out in the documentation by >> >having dpdk-lcore- mask the same as pmd-cpu-mask, OVS cannot even be >> >killed (a kill -9 is required). I wonder what happens if one tries >> >to set pmd-cpu-mask to every core in the system. >> >As a way to mitigate the risk perhaps we can avoid setting the main >> >thread affinity to the first core in dpdk-lcore-mask by _always_ >> >restoring it in dpdk_init__(), also if auto_determine is false. >> >Perhaps we should start explicitly prohibiting creating a pmd thread >> >on the first core in dpdk-lcore-mask (I get why previous version of >> >this didn't do it on core 0. Perhaps we can generalize that to the first >> >core >in dpdk-lcore-mask). >> I will look in to this and get back to you sometime next week. > >Isn't enough to just increase priority to the max with setpriority(2)? >I know it is not the same as SCHED_RR but for those users that don't know >how to tune it properly, this seems to be less dangerous while still providing >a >good share of CPU to the PMD thread. I agree with your suggestion here. Though my initial patch was to address pmd thread starvation case, I see now that I have put some restriction around the pmd-cpu-mask affinity setting by not spawning the pmd thread on the first core of the dpdk-lcore-mask due to the way DPDK handles the thread pinning . You can check the patch here: http://openvswitch.org/pipermail/dev/2016-August/078001.html At this point In time I would bump up the pmd thread priority instead of changing the policty to SCHED_RR as this Is less dangerous and would allow users with fewer cores to still set pmd-cpu-mask. > >For instance, I recall to have seen OVS revalidation threads running with PMD >on the same CPU, but that might have been 2.5 only. This is seen even with latest OVS Master. Here is the way you can reproduce this. From the below output you can see that the ovs-vswitchd, revalidators threads are running on the same core as pmd thread. $ ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=F0 $ ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=10 $ ps -eLo tid,psr,comm | grep -e lcore -e revalidator -e ovs-vswitchd -e pmd 89966 4 ovs-vswitchd 89969 5 lcore-slave-5 89970 6 lcore-slave-6 89971 7 lcore-slave-7 90038 4 revalidator37 90039 4 revalidator52 90040 4 revalidator42 90041 4 revalidator38 90042 4 revalidator39 90043 4 revalidator45 90044 4 revalidator53 90045 4 revalidator54 90047 4 pmd61 > >Thanks, >-- >fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
