On Monday 01 August 2016 09:14 PM, Ben Pfaff wrote:
On Mon, Aug 01, 2016 at 07:03:14PM +0530, Babu Shanmugam wrote:
On Thursday 28 July 2016 01:48 AM, Ben Pfaff wrote:
On Wed, Jul 20, 2016 at 08:02:03PM +0530,bscha...@redhat.com wrote:
ovn-northd processes the list of Port_Bindings and hashes the list of
queues per chassis. When it finds a port with qos_parameters and without
a queue_id, it allocates a free queue for the chassis that this port belongs.
The queue_id information is stored in the options field of Port_binding table.
Adds an action set_queue to the ingress table 0 of the logical flows
which will be translated to openflow set_queue by ovn-controller
ovn-controller opens the netdev corresponding to the tunnel interface's
status:tunnel_egress_iface value and configures a HTB qdisc on it. Then for
each SB port_binding that has queue_id set, it allocates a queue with the
qos_parameters of that port. It also frees up unused queues.
This patch replaces the older approach of policing
Signed-off-by: Babu Shanmugam<bscha...@redhat.com>
I suggest folding in the following changes. Notably, set_queue(0); was
documented but didn't work because QDISC_MIN_QUEUE_ID was 1.
This series has no tests. I think that at least the DSCP marking
feature could be tested with the existing OVN testing infrastructure.
Will you work on that?
Ben,
I am trying to write a test case with the following sequence to test the
dscp marking.
- Add two ports (lp1, lp2) through ovn-nbctl and assign addresses
- Setup the vswitch db with external_ids:iface-id for the logical ports
created above
- Set options:qos_dscp on one logical port (lp1) through ovn-nbctl
- ofproto/trace a simple ip packet originating from lp1, and check if the
final flow has the DSCP bit set or not
ofproto/trace is tracing out correctly only when qos_dscp is not set. When
qos_dscp is set, the controller adds includes an additional action
"0x22->OXM_OF_IP_DSCP[]" in table 16. With this, ofproto/trace says it drops
the packet after it passes through table 0.
Do you have any suggestion on how to overcome this?
Hmm, that's odd. What's the whole trace output look like?
It looks like the following
$ ovs-appctl ofproto/trace br-int
'in_port=1,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01' -generate
Bridge: br-int
Flow:
in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
Rule: table=0 cookie=0 priority=100,in_port=1
OpenFlow
actions=set_field:0x1->reg13,set_field:0x1->metadata,set_field:0x1->reg14,resubmit(,16)
Resubmitted flow:
reg13=0x1,reg14=0x1,metadata=0x1,in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
Resubmitted regs: reg0=0x0 reg1=0x0 reg2=0x0 reg3=0x0 reg4=0x0
reg5=0x0 reg6=0x0 reg7=0x0 reg8=0x0 reg9=0x0 reg10=0x0 reg11=0x0
reg12=0x0 reg13=0x1 reg14=0x1 reg15=0x0
Resubmitted odp: drop
Resubmitted megaflow:
recirc_id=0,reg13=0,reg14=0,metadata=0,in_port=1,vlan_tci=0x0000/0x1000,dl_src=f0:00:00:00:00:02,dl_type=0x0000
Rule: table=254 cookie=0 priority=0,reg0=0x2
OpenFlow actions=drop
Final flow:
reg13=0x1,reg14=0x1,metadata=0x1,in_port=1,vlan_tci=0x0000,dl_src=f0:00:00:00:00:02,dl_dst=f0:00:00:00:00:01,dl_type=0x0000
Megaflow:
recirc_id=0,in_port=1,vlan_tci=0x0000/0x1000,dl_src=f0:00:00:00:00:02,dl_type=0x0000
Datapath actions: drop
--
Babu
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
