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

Reply via email to