Hello Kevin, > >Rxqs are scheduled to be handled across available pmds in round robin order >with no weight or priority. > >It can happen that some very busy queues are handled by one pmd which >does not have enough cycles to prevent packets being dropped on them. >While at the same time another pmd which handles queues with no traffic on >them, is essentially idling. > >Rxq scheduling happens as a result of a number of events and when it does, >the same unweighted round robin approach is applied each time. > >This patchset proposes to augment the round robin nature of rxq scheduling >by counting the processing cycles used by the rxqs during their operation and >incorporate it into the rxq scheduling. > >Before distributing in a round robin manner, the rxqs will be sorted in order >of >the processing cycles they have been consuming. Assuming multiple pmds, >this ensures that the measured rxqs using most processing cycles will be >distributed to different cores.
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 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
