On Tue, May 17, 2016 at 05:40:27PM +0530, Babu Shanmugam wrote: > Hi, > Following are my thoughts on how we can do egress shaping and dscp marking > in OVN from what I understood from this > <http://openvswitch.org/pipermail/dev/2016-May/070599.html> mail thread; > > - Client sets the rate, burst and dscp parameters in 'options' field on the > NB Logical_Port table. > - ovn-northd does the following > - Figures out a free queue number and sets it in the 'options' field of > SB Port_Binding table > - Copies the rate and burst parameters from NB Logical_Port table. > - Sets new actions 'set_queue(queue_number)' and > 'mark_dscp(dscp_value)' in Logical_Flow that corresponds to the 'inport' in > the ls_in_port_sec_l2 stage. > - ovn-controller does the following > - Opens the netdev that has the 'ovn-encap-ip' address. Does > 'ovn-encap-ip' always belong to a physical device? Is there a better way in > finding a physical interface? > - Checks and creates qdisc of type linux-htb/linux-hfsc > - Checks and creates queues for all the logical ports and sets rate, > burst parameters > - Implements the necessary openflow actions for 'set_queue' and > 'mark_dscp' logical actions
This sounds reasonable to me. I'm adding Bryan Fulton again in case he has an opinion. The best way to find the "physical" interface that a tunnel egresses is probably to use status:tunnel_egress_iface in the Interface table. (Solving this QoS problem is in fact why that status key exists, if I recall correctly.) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev