Hi Bhanu, On 05/21/2017 10:25 PM, Bodireddy, Bhanuprakash wrote: > 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 >
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. thanks, Kevin. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
