[ovs-discuss] prioritizing latency-sensitive traffic
Ben Pfaff
blp at ovn.org
Thu Apr 13 18:47:01 UTC 2017
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-bounces at openvswitch.org [mailto:ovs-discuss-
> > bounces at openvswitch.org] On Behalf Of O Mahony, Billy
> > Sent: Friday, November 25, 2016 5:04 PM
> > To: ovs-discuss at 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
> > discuss at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
More information about the discuss
mailing list