[ovs-dev] [PATCH 4/4] [RFC] ofproto-dpif: Make ofproto/trace output easier to read.

[Ben Pfaff]

On Wed, Dec 07, 2016 at 12:31:24PM -0500, Lance Richardson wrote:
> > From: "Ben Pfaff" <blp at ovn.org>
> > To: dev at openvswitch.org
> > Sent: Wednesday, December 7, 2016 11:36:13 AM
> > Subject: Re: [ovs-dev] [PATCH 4/4] [RFC] ofproto-dpif: Make ofproto/trace output easier to read.
> > 
> > On Tue, Dec 06, 2016 at 11:28:43PM -0800, Ben Pfaff wrote:
> > > "ovs-appctl ofproto/trace" is invaluable for debugging, but as the users of
> > > Open vSwitch have evolved it has failed to keep up with the times.  It's
> > > pretty easy to design OpenFlow tables and pipelines that resubmit dozens of
> > > times.  Each resubmit causes an additional tab of indentation, so the
> > > output wraps around, sometimes again and again, and makes the output close
> > > to unreadable.
> > > 
> > > ovn-trace pioneered better formatting for tracing in OVN logical datapaths,
> > > mostly by not increasing indentation for tail recursion, which in practice
> > > gets rid of almost all indentation.
> > > 
> > > This commit experiments with redoing ofproto/trace the same way.  Try
> > > looking at, for example, the testsuite output for test 2280 "ovn -- 3 HVs,
> > > 3 LRs connected via LS, source IP based routes".  Without this commit, it
> > > indents 61 levels (488 spaces!).  With this commit, it indents 1 level
> > > (4 spaces) and it's possible to actually understand what's going on almost
> > > at a glance.
> > 
> > Here's the output with this patch, followed by the output without this
> > patch:
> > 
> 
> Having tried to make sense of the current format before (successfully, eventually,
> but with great effort): thank you for doing this, it should make debugging and
> understanding OVN much easier.
> 
> However, with this 4-patch series applied I'm getting test failures that I don't
> see without these patches:
> 
> 1169: ofproto-dpif - trace (unchanged)                FAILED (ofproto-dpif.at:8321)
> 1052: ofproto-dpif - fragment handling - trace        FAILED (ofproto-dpif.at:3799)
> 2161: RSTP - dummy interface                          FAILED (rstp.at:215)
> 2154: STP - dummy interface                           FAILED (stp.at:430)
> 1082: ofproto-dpif - ofproto/trace command 1          FAILED (ofproto-dpif.at:4842)
> 1084: ofproto-dpif - ofproto/trace from dpctl output  FAILED (ofproto-dpif.at:5000)

Yes, fixing these are on the to-do list that will need to be finished
before it becomes non-RFC.  (There may be genuine bugs, but these are
mostly for tests that are very picky about the output format, so they
break because the output format changed.)