On 12 April 2017 at 10:53, Flavio Leitner <[email protected]> wrote: > On Wed, Apr 12, 2017 at 10:04:50AM -0700, Joe Stringer wrote: >> On 12 April 2017 at 08:22, Flavio Leitner <[email protected]> wrote: >> > On Fri, Apr 07, 2017 at 04:13:08PM +0300, Roi Dayan wrote: >> >> From: Paul Blakey <[email protected]> >> >> >> >> Usage: >> >> # to dump all datapath flows (default): >> >> ovs-dpctl dump-flows >> >> >> >> # to dump only flows that in kernel datapath: >> >> ovs-dpctl dump-flows type=ovs >> >> >> >> # to dump only flows that are offloaded: >> >> ovs-dpctl dump-flows type=offloaded >> > >> > >> > It should return an error if the type= is wrong/unavailable. >> >> I wonder if we should also add a piece in verbose mode (-m) at the end >> of each flow that says something like "type=software", "type=hardware" >> (which should match the name of the ovs-dpctl dump-flows type >> argument)? > > Makes sense. Perhaps offloaded isn't the correct term, neither > software or hardware, because it seems TC can decide to not offload to > the HW and that is not visible to OVS. As a result, you could pass > "type=offloaded" and see rules that are actually in TC software. > Perhaps I missed something.
wrt 'offloaded', seems fine to me. If it's offloaded from regular OVS path to TC path, even in software, this is still more accurately describing what happened than to say 'hardware' since the tc-policy could be sw-only. So 'ovs' and 'offloaded' seem OK. The main point I was highlighting above was that if you just dumped the flows in regular mode, you don't have any indication where the flows are being executed. Maybe that's fine, but if ovs-dpctl dump-flows ends up printing both sources it might be easier to notice something odd going on if there were an indication where the flow came from. The tradeoff is we end up printing even more information on the commandline, hence why I figured it might be better to only display it in verbose mode. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
