[ovs-dev] [PATCH] INSTALL.DPDK.md: Clarify DPDK arguments.

Traynor, Kevin kevin.traynor at intel.com
Tue Dec 22 16:00:17 UTC 2015


> -----Original Message-----
> From: Zoltan Kiss [mailto:zoltan.kiss at linaro.org]
> Sent: Tuesday, December 15, 2015 6:56 PM
> To: Traynor, Kevin; Aaron Conole
> Cc: dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] INSTALL.DPDK.md: Clarify DPDK arguments.
> 
> Hi,
> 
> On 15/12/15 14:50, Traynor, Kevin wrote:
> >> Seems good, assuming that the thread affinity at the time dpdk_init()
> >> >was called reflects what cores are allowed for non-PMD threads. And what
> >> >if the user wants to change that later?
> > Hi - not sure what you mean by "allowed for non-PMD threads". Is there an
> example?
> 
> I don't know how OVS determines the cores where non-PMD threads should
> run. I guess the most basic requirement is that they should NOT be on
> the PMD cores, if possible.

Hi Zoltan, sorry for the delayed response. 

yeah, at present it's just based on the -c. So the user will have knowledge
of what is being used for pmd and non-pmd. Ideally, we can start to create
defaults where that knowledge is not needed. 

> But then, you revert the affinity changes made by rte_eal_init(), so the
> only thing we set with the -c value is the lcore_id of the calling
> thread. I guess that doesn't have too much relevance. Or is there any
> case where the affinity of the non-PMD thread (which calls
> rte_eal_init()), changes, and lcore_id should follow that?

That's an interesting point - if the affinity floated across non-isolcpu'd
cores, it would be fine. If someone explicitly taskset it then I think we
may need to add a few LOC to account for that. It should be straightforward
to catch though.

> 
> Zoli


More information about the dev mailing list