[ovs-dev] [RFC v2] lib/table: add new flexible formatting

Ben Pfaff blp at ovn.org
Tue Dec 20 01:54:44 UTC 2016


On Tue, Dec 13, 2016 at 04:43:32PM -0500, Aaron Conole wrote:
> Ben Pfaff <blp at ovn.org> writes:
> 
> > On Mon, Dec 12, 2016 at 08:11:16PM -0500, Aaron Conole wrote:
> >> Ben Pfaff <blp at ovn.org> writes:
> >> 
> >> > On Wed, Dec 07, 2016 at 02:15:12PM -0500, Aaron Conole wrote:
> >> >> Ben Pfaff <blp at ovn.org> writes:
> >> >> > On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote:
> >> >> >> Ben Pfaff <blp at ovn.org> writes:
> >> >> >> To accomplish this, I'm going down the following route:
> >> >> >> 
> >> >> >> 1. Add formatting option to the lib/table.{c,h}, such that we can
> >> >> >>    still express the existing output.
> >> >> >> 
> >> >> >> 2. Change ofp-print to use a table for flow dumping, with a default
> >> >> >>    format that preserves the current format, and the option of changing
> >> >> >>    the format.
> >> >> >
> >> >> > #2 is interesting.
> >> >> 
> >> >> I don't currently see how to implement #2, while preserving the existing
> >> >> output, unless I implement #1.  Is there a way to accomplish this that
> >> >> I'm missing?  If not, is #2 compelling enough to accept #1?
> >> >
> >> > I don't understand how you are going to preserve the default format even
> >> > with #1.  I assumed you were going to need to write a separate code path
> >> > to do that.
> >> 
> >> No - that's my last resort.
> >> 
> >> > Can you explain your plan?
> >> 
> >> I was thinking of creating a table which had column headings that were,
> >> example:
> >> 
> >>   actions, in_port, priority, table number, etc.
> >> 
> >> Then a format string such as:
> >> 
> >>   [priority={priority},][table={tableno},]...
> >> 
> >> where things in the [] would only be printed if all elements in the row
> >> were filled in, could preserve the original output (without the full
> >> working code set it might be difficult to see what I mean), while also
> >> offering the existing --table=XXX output.
> >
> > This may be challenging because of the number of columns.  in_port is
> > easy enough, but OVS has dozens (at least) of possible fields.  It also
> > has a nonuniform way to display fields.  For example, it shows the
> > Ethernet type in a general form as "dl_type=0x1234", but if it's an IP
> > packet then it just says "ip" instead, and if it's TCP then it just says
> > "tcp" instead of "dl_type=0x0800,nw_proto=6", and so on.
> 
> I enjoy a challenge from time to time ;-)
> 
> Moreover, I'm willing to do the work.  Agreed, there's lots of it
> (dozens is right), but I think it's an elegant solution.

Do you have a basic plan for how to do it?  There's definitely room for
better display here, but I want the code to be clean and maintainable.


More information about the dev mailing list