On Thu, Oct 18, 2012 at 12:51:55PM -0700, Justin Pettit wrote: > These commands will be useful in a future commit that makes multiple > bridges share a single backing datapath. The ovs-dpctl commands will > show information about the backing datapath, so it will be difficult to > determine which information belongs to which bridge. The new "dpif/*" > ovs-appctl commands return information about the bridge--regardless of > how the backing datapath is configured. > > Signed-off-by: Justin Pettit <jpet...@nicira.com>
Users are already confused enough (and rightly so) about the difference between "ovs-ofctl dump-flows" and "ovs-dpctl dump-flows" (and other uses of these programs). Adding a third way is going to make their heads spin. I suggest adding some explanation to the manpage text for each program/fragment, and perhaps a FAQ entry giving an overview. dpif/dump-dps and dpif/show both need a sorted list of ofprotos, perhaps they could team up. It might be wise to sort the ofprotos on type@name instead of just name. For consistency with ovs-dpctl it might be nice if dpif/show would accept multiple names at once. "ovs-dpctl show" prints a colon on the line that introduces a datapath name, "dpif/show" omits it. I'd drop the following change from vswitchd/ovs-vswitchd.8.in: @@ -122,10 +122,11 @@ interfaces if none is given) to be \fIstatus\fR. \fIstatus\fR can be "true", "false", or "normal" which reverts to the standard behavior. .IP "\fBstp/tcn\fR [\fIbridge\fR]" Forces a topology change event on \fIbridge\fR if it's running STP. This may cause it to send Topology Change Notifications to its peers and flush its MAC table.. If no \fIbridge\fR is given, forces a topology change +. event on all bridges. .SS "BRIDGE COMMANDS" These commands manage bridges. .IP "\fBfdb/flush\fR [\fIbridge\fR]" Flushes \fIbridge\fR MAC address learning table, or all learning tables Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
