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. 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: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss- > > boun...@openvswitch.org] On Behalf Of O Mahony, Billy > > Sent: Friday, November 25, 2016 5:04 PM > > To: ovs-discuss@openvswitch.org > > 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 > > disc...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss