Hi Ben, Darrell, I've done some PoC work on this kind of traffic prioritization. However with OVS-DPDK's run-to-completion model the issue I find the same issue as you outlined - by the time the priority of the packet has been determined most of the effort to process the packet has already been spent.
So, I relied on using hardware offload i.e. FlowDirector on the NIC to analyse and allocate packets to high and low priority queues and then modifying the PMD (dpif_netdev_run ) to read preferentially from the high priority queue. The results were good for overload situations - packets on the priority queue not dropped. In terms of latency there was an improvement but there was still a long tail to the latency profile. i..e The latency profile moved down but not left. As Darrell pointed out for egress scheduling, perhaps this kind of ingress prioritization can be encapsulated as an optional property of a port? If the port can implement the prioritization (either by offloading to hardware or in software) it can accept the property being set; If not it can return ENOTSUPP? There is currently HWOL use-cases being gathered for OVS-DPDK: https://docs.google.com/document/d/1A8adu1xzg53bzcFKINhffYyC0nCQjqwqnI1jAFx2sck/edit?usp=sharing + Kevin who is co-ordinating that. Thanks, Billy. > -----Original Message----- > From: Ben Pfaff [mailto:[email protected]] > Sent: Friday, April 21, 2017 10:39 PM > To: O Mahony, Billy <[email protected]> > Cc: [email protected]; Darrell Ball <[email protected]> > Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic > > Thanks for letting us know. I'm happy to continue the conversation if there > are interesting ideas; it's a frustrating situation, frankly, and I'd love to > hear > creative approaches. > > On Tue, Apr 18, 2017 at 10:01:28AM +0000, O Mahony, Billy wrote: > > Hi Ben, Darrell, > > > > It sounds like the general feeling is that any kind of tc pre-processing is > > not > worth it and the existing egress queing/QoS facilities should suffice. > > > > Thanks for your comments. > > > > /Billy > > > > > > > > > -----Original Message----- > > > From: Ben Pfaff [mailto:[email protected]] > > > Sent: Thursday, April 13, 2017 7:47 PM > > > To: O Mahony, Billy <[email protected]> > > > Cc: [email protected] > > > Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic > > > > > > I don't know how much more OVS can contribute to this than it already > does. > > > By the time that OVS has classified a packet to the extent that is > > > necessary to determine that it should be handled with a high > > > priority, OVS has already done most of the work that it does on a packet. > > [[BO'M]] I'm investigating how I could go about classifying packets > > before the main The work to transmit the > > > packet is not part of OVS's job, it is the job of the driver, and at > > > most OVS can mark the packet with a priority or a queue. OVS can > > > already do that. So the usual answer is that it's a matter of > > > configuring QoS in the driver to do what the user wants. > > > > > > On Mon, Apr 10, 2017 at 09:30:12AM +0000, O Mahony, Billy wrote: > > > > Hi Everybody, > > > > > > > > I just wanted to reflag this discussion below about possible > > > > methods of > > > how to prioritize certain types of traffic handled by OVS. > > > > > > > > By prioritize I mean either or both of: > > > > a) 'priority' packets are sent to their destination port faster > > > > than other packets > > > > b) in an overloaded situation the switch drops non-prioritized > > > > packets > > > rather than prioritized packets. > > > > > > > > Also just to be clear I am discussing kernel ovs here. Also I'm > > > > looking at > > > doing this without writing new code - ie is it possible and if so > > > how is it configured using existing OVS. > > > > > > > > Thanks again, > > > > Billy. > > > > > > > > > -----Original Message----- > > > > > From: [email protected] [mailto:ovs-discuss- > > > > > [email protected]] On Behalf Of O Mahony, Billy > > > > > Sent: Friday, November 25, 2016 5:04 PM > > > > > To: [email protected] > > > > > Subject: [ovs-discuss] prioritizing latency-sensitive traffic > > > > > > > > > > Hi, > > > > > > > > > > I have been performing tests investigating latency profiles of > > > > > low-bandwidth time-sensitive traffic when the system is busy > > > > > with > > > 'normal' traffic. > > > > > Unsurprisingly the latency-sensitive traffic is affected by the > > > > > normal traffic and has basically the same latency profile as the > > > > > normal > > > traffic. > > > > > > > > > > I would like to be able to perform prioritization of traffic as > > > > > some protocols such as PTP would benefit greatly from having > > > > > it's packets 'jump > > > the queue'. > > > > > > > > > > From skimming the documentation it looks that ingress QoS offers > > > > > only policing (rate-limiting). Is this actually the case or > > > > > maybe I'm not looking in the right place? > > > > > > > > > > But if so, I am looking at some alternatives: > > > > > > > > > > a) create two separate egress ports and have PTP listen on one > > > > > port, everything else listen on the other port and use normal > > > > > forwarding rules to send PTP traffic incoming from eth0 to it's > > > > > own port. Something > > > like: > > > > > > > > > > other apps ptp_daemon > > > > > + + > > > > > + + > > > > > if_norm if_ptp > > > > > + + > > > > > | | > > > > > | | > > > > > ++------------++ > > > > > | | > > > > > | ovs | > > > > > | | > > > > > +-----+--------+ > > > > > | > > > > > + > > > > > eth0 > > > > > > > > > > b) create prioritized queues on a port and use match and actions > > > > > such as > > > > > set_queue(queue) and enqueue(port, queue) on ingress traffic to > > > > > forward the PTP traffic to the higher priority queue. However I > > > > > think queue priority for this case only relates to which queue > > > > > get to consume the bandwidth of the port first and not about > > > > > changing the order in which the packets egress the port. > > > > > > > > > > c) Or perhaps I can re-use tc PRIO or CBQ qdiscs by passing all > > > > > traffic to tc first before ovs? > > > > > > > > > > other apps > > > > > | > > > > > | > > > > > if_norm > > > > > + > > > > > | > > > > > | > > > > > +--------------+ > > > > > | | > > > > > | ovs | > > > > > | | > > > > > +-----+--------+ > > > > > | > > > > > | > > > > > tc ----- if_ptp ---- ptp_daemon > > > > > + > > > > > eth0 > > > > > > > > > > Any thoughts, ideas or clarifications most welcome. > > > > > > > > > > Thanks, > > > > > Billy. > > > > > > > > > > _______________________________________________ > > > > > discuss mailing list > > > > > [email protected] > > > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > > > _______________________________________________ > > > > discuss mailing list > > > > [email protected] > > > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
