On Tue, Aug 02, 2016 at 03:06:26PM +0530, Babu Shanmugam wrote: > > > On Monday 01 August 2016 10:09 PM, Babu Shanmugam wrote: > > > > > >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 > > > > Turns out that it was due to a bug in the DSCP marking code. The DSCP > marking was done at L2 stage without any additional flows to handle the L2 > packets itself. So any L3 packet gets dropped at this stage. > I moved the DSCP marking logic to L3 pipeline with additional tests and > submitted the patches for review.
I'm glad you figured it out. I found the trace surprising and had decided to look again later. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev