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. 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. Thanks, -- fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
