>> 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
