[ovs-dev] [RFC PATCH 0/6] Change dpdk rxq scheduling to incorporate rxq processing cycles.

Bodireddy, Bhanuprakash bhanuprakash.bodireddy at intel.com
Mon May 22 16:04:03 UTC 2017


>> Thanks for working on this. This work is important and would also solve OvS-
>DPDK scaling issue.
>> I have reviewed the patch series but haven't tested this yet with traffic. I
>would stick to comments on high level design at his stage.
>>
>> With this series, rxqs are sorted based on cycles consumed and are
>subsequently distributed across multiple PMDs in round robin fashion. While
>this approach is fine, I have some concerns w.r.t QoS.
>>
>> Now OvS-DPDK don't support QoS (i.e based on L2 - pcp, L3 - dscp bits). But
>when QoS is implemented in future based on Weighted Round Robin(WRR),
>Strict priority(SP) (or) hybrid models(WRR and SP) the proposed approach in
>this RFC may conflict or pose some limitations.
>>
>> I am aware that this RFC doesn't factor in QoS, but would like to know your
>thoughts and if you have some ideas to  make it less painful in future.
>>
>> 1)  In WRR/SP model, the rxq(s) shall be sorted according to queue
>credits/priorities.  PMD may have to poll rxq(s) based on this criteria?
>> 2) For example, signaling/control traffic which is high priority may be
>redirected to a specific rxq(based on pcp/dscp bits) in most of the scenarios.
>Also the control traffic can be <= 5% of total traffic and hence the cycles spent
>on this queue can be insignificant and these rxq(s) shall be pushed to the end
>of the sorted list as per the proposed approach. Most importantly rxq
>receiving the *high volume lowest priority traffic* will top the list always and
>shall be processed first by the respective PMD threads potentially tail
>dropping *low rate high priority traffic* during congestion.
>>
>> Also adding Billy from Intel who is working QoS for OvS-DPDK.
>>
>> - Bhanuprakash
>>
>
>Thanks for your comments. I can only speculate based on the high level
>description of QoS but I don't think it should be an issue. Think of this RFC as a
>refinement of the default round robin queue to core assignment.
>
>At the moment, the rxq affinity pinning takes precedence over the default
>assignment. I would expect that a user defined QoS should also take
>precedence, but that there will be still be a need for code to perform the
>default assignment because QoS would be optional and/or queues may have
>equal priorities.

This makes sense. I will try to test this series with some traffic.

- Bhanuprakash.


More information about the dev mailing list