On Mon, May 08, 2017 at 11:47:46AM -0400, Aaron Conole wrote: > Hi Ben, > > Thanks for the look! > > Ben Pfaff <[email protected]> writes: > > > On Fri, Apr 28, 2017 at 04:44:32PM -0400, Aaron Conole wrote: > >> Greetings dev, > >> > >> I have whipped up a quick little utility (find below), that I've done a > >> bit of debugging with and it seems to have made working with dump-flows > >> from ovs-ofctl a little easier to use. > >> > >> If you think it's worthwhile to add to the repository, I'll submit it > >> formally. We were using it while debugging some strange packet > >> forwarding in openshift. > >> > >> -Aaron > > > > Thanks for working to make the ovs-ofctl formatting better! > > > > I prefer to interpret this script as a kind of "feature request" for > > "ovs-ofctl dump-flows". This command already has some special support, > > compared to other ovs-ofctl commands, and it might make sense to > > continue adding to it. > > In which way? It calls the same ofp-print code, iirc. > > > ovs-ofctl dump-flows already has one of the features that this script > > adds, that is, sorting the flows and removing "OFPST_FLOW" lines. You > > turn this on by using the "--sort" (or "--rsort") option. > > Ahh, cool - I missed that. > > > The other features that this script provides all seem like ones that > > would be useful to add to ovs-ofctl itself. I'd tend to prefer to > > continue enhancing it rather than adding wrapper scripts; I think that > > this is likely to yield a more coherent design in the end, and possibly > > higher quality. Is that something you're willing to consider? > > I had started to work on this, back in December, but there were hundreds > of lines of existing formatting code that would have to change (this is > related to the discussion here: > https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326560.html), > and I thought it might be a better use of time to simply wrap the output > - especially since I didn't know if any future changes in that area were > going to happen. The last thing I want to do is break the existing > output (which I do use quite a bit for debugging, so retraining myself > would be painful) if someone has scripts which rely on it. > Additionally, quite a few print commands would have changed to give the > data to the table structure, rather than a long string. It looked to be > a rather large change for something that could be resolved with a > wrapper. Maybe I misinterpreted your response (from here > https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326201.html). > > The other thing that adds complication is replacing the port numbers > with names from the database. That would require a second transaction > (unless there's a way to batch that during the initial dump-flows > request, but I couldn't see an obvious way), and I didn't know if it > would be okay to do (and how to treat failures... after all, it's > convenient, but it isn't requisite to have the numbers replaced with > names). There are a few minor changes I have to my copy of the script > (I've added back the packet counts, and I have the port output in a way > that we can not-quite paste the flow back in to an add-flow), but I > ended up also using the direct output of dump-flows. > > As for how to implement it, I could have put some kind of post processor > that would split the strings up (the way I have done with the script), > but that felt rather hacky (since it's basically the formatting script, > but in c-code form). > > Anyway, I submitted this as a start. If you think it's better to do the > work in the ofp-print library then I can revisit it. Maybe the reduced > set of things that were really helpful, and the rest we can just say > "don't fear sed".
Since this discussion, I've added what I think are the script's most important features directly to ovs-ofctl. Are the remaining features, not yet in ovs-ofctl, important you? Which ones? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
