Ben Pfaff <[email protected]> writes:

> 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?

No, they aren't.  We have resolved the related issue in our BZ.  Thanks.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to