[ovs-discuss] [ovs-dev] OVS DPDK NUMA pmd assignment question for physical port

Kevin Traynor ktraynor at redhat.com
Wed Sep 6 14:02:27 UTC 2017

On 09/06/2017 02:43 PM, Jan Scheurich wrote:
>> I think the mention of pinning was confusing me a little. Let me see if I fully understand your use case:  You don't 'want' to pin
>> anything but you are using it as a way to force the distribution of rxq from a single nic across to PMDs on different NUMAs. As without
>> pinning all rxqs are assigned to the NUMA-local pmd leaving the other PMD totally unused.
>> But then when you used pinning you the PMDs became isolated so the vhostuser ports rxqs would not be assigned to the PMDs unless
>> they too were pinned. Which worked but was not manageable as VM (and vhost ports) came and went.
>> Yes?
> Yes!!!
>> In that case what we probably want is the ability to pin an rxq to a pmd but without also isolating the pmd. So the PMD could be
>> assigned some rxqs manually and still have others automatically assigned.
> Wonderful. That is exactly what I have wanted to propose for a while: Separate PMD isolation from pinning of Rx queues. 
> Tying these two together makes it impossible to use pinning of Rx queues in OpenStack context (without the addition of dedicated PMDs/cores). And even during manual testing it is a nightmare to have to manually pin all 48 vhostuser queues just because we want to pin the two heavy-loaded Rx queues to different PMDs.

That sounds like it would be useful. Do you know in advance of running
which rxq's they will be? i.e. you know it's particular port and there
is only one queue. Or you don't know but analyze at runtime and then

> The idea would be to introduce a separate configuration option for PMDs to isolate them, and no longer automatically set that when pinning an rx queue to the PMD.

Please don't break backward compatibility. I think it would be better to
keep the existing command as is and add a new softer version that allows
other rxq's to be scheduled on that pmd also.


> BR, Jan

More information about the discuss mailing list