On Wed, Dec 21, 2016 at 10:07:51AM -0500, Aaron Conole wrote: > Ben Pfaff <[email protected]> writes: > > > On Tue, Dec 13, 2016 at 04:43:32PM -0500, Aaron Conole wrote: > >> Ben Pfaff <[email protected]> writes: > >> > >> > On Mon, Dec 12, 2016 at 08:11:16PM -0500, Aaron Conole wrote: > >> >> Ben Pfaff <[email protected]> writes: > >> >> > >> >> > On Wed, Dec 07, 2016 at 02:15:12PM -0500, Aaron Conole wrote: > >> >> >> Ben Pfaff <[email protected]> writes: > >> >> >> > On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote: > >> >> >> >> Ben Pfaff <[email protected]> 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. > > So, every plan that I've gone through starts with a separate code path > for the table approach if I want to stage it. > > It probably makes sense to start there, and add the fields I've been > requested to add, first, and as part of the same series hook up > ovs-ofctl dump-flows to call that new code path. > > Does that make sense?
Sure. I'd prefer to make the whole thing a single series because in this case I don't want to add library code that won't be used, but it sounds like you already plan to do it that way. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
