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? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
