[ovs-dev] [PATCH] ovn-trace: Print stage name even without match.

Russell Bryant russell at ovn.org
Fri Nov 11 03:40:22 UTC 2016


On Thu, Nov 10, 2016 at 3:37 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Thu, Nov 10, 2016 at 02:01:14PM -0800, Russell Bryant wrote:
> > On Thu, Nov 10, 2016 at 1:40 PM, Ben Pfaff <blp at ovn.org> wrote:
> >
> > > On Thu, Nov 10, 2016 at 03:54:16PM -0500, Russell Bryant wrote:
> > > > Given a simple OVN configuration and a sample packet that fails to
> match
> > > > an L2 destination lookup flow, the output of ovn-trace looks
> something
> > > > like this:
> > > >
> > > >     $ ovn-trace --detailed sw0 'inport == "sw0-port1" && eth.src ==
> > > 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:ff'
> > > >     # reg14=0x1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=
> > > 00:00:00:00:00:ff,dl_type=0x0000
> > > >
> > > >     ingress(dp="sw0", inport="sw0-port1")
> > > >     -------------------------------------
> > > >      0. ls_in_port_sec_l2 (ovn-northd.c:2827): inport == "sw0-port1"
> &&
> > > eth.src == {00:00:00:00:00:01}, priority 50
> > > >         next(1);
> > > >     13. no match
> > > >
> > > > In this case, I think it is helpful to still display the name of the
> > > > pipeline stage where we failed to match a flow.  This patch adds
> > > > that to the output.  This patch assumes that we always use the
> > > > same stage name for a given table ID in a given datapath, but I'm
> > > > pretty sure that is always true.
> > > >
> > > >     ingress(dp="sw0", inport="sw0-port1")
> > > >     -------------------------------------
> > > >      0. ls_in_port_sec_l2 (ovn-northd.c:2827): inport == "sw0-port1"
> &&
> > > eth.src == {00:00:00:00:00:01}, priority 50
> > > >         next(1);
> > > >     13. ls_in_l2_lkup: no match
> > > >
> > > > Signed-off-by: Russell Bryant <russell at ovn.org>
> > >
> > > Acked-by: Ben Pfaff <blp at ovn.org>
> > >
> > > Why the xstrdup() though?
> > >
> >
> > I can remove it if you want.  I was just trying to be safe and not have
> the
> > caller worry about how long the return value is valid for.
>
> Either way.
>

OK.  I applied this to master as-is.

-- 
Russell Bryant



More information about the dev mailing list