> >> +If using ``pmd-rxq-assign=group`` PMD threads with *pinned* Rxqs can
> >> +be
> >> +*non-isolated* by setting::
> >> +
> >> +  $ ovs-vsctl set Open_vSwitch . other_config:pmd-rxq-isolate=false
> >
> > Is there any specific reason why the new pmd-rxq-isolate option should be
> limited to the "group" scheduling algorithm? In my view it would make more
> sense and simplify documentation and code if these aspects of scheduling were
> kept orthogonal.
> >
> 
> David had a similar comment on an earlier version. I will add the fuller reply
> below. In summary, pinning and the other algorithms (particularly if there was
> multiple pinnings) conflict in how they operate because they are based on RR
> pmd's to add equal number of Rxqs/PMD.
> 
> ---
> Yes, the main issue is that the other algorithms are based on a pmd order on
> the assumption that they start from empty. For 'roundrobin' it is to equally
> distribute num of rxqs on pmd RR - if we pin several rxqs on one pmds, it is 
> not
> clear what to do etc. Even worse for 'cycles' it is based on placing rxqs in 
> order
> of busy cycles on the pmds RR. If we pin an rxq initially we are conflicting
> against how the algorithm operates.
> 
> Because 'group' algorithm is not tied to a defined pmd order, it is better 
> suited
> to be able to place a pinned rxq initially and be able to consider that pmd on
> it's merits along with the others later.
> ---

Makes sense. The legacy round-robin and cycles algorithms are not really 
prepared for pinned rxqs.

In our patch set we had replaced the original round-robin and cycles algorithms 
with a single new algorithm that simply distributed the rxqs to the 
"least-loaded" non-isolated PMD (based on #rxqs or cycles assigned so far). 
With pinning=isolation, this exactly reproduced the round-robin behavior and 
created at least as good balance as the original cycles algorithm. In that new 
algorithm any pinned rxqs were already considered and didn't lead to distorted 
results.

BR, Jan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to