[ovs-dev] [Single DP 10/15] ofproto-dpif: Add ovs-appctl commands for ovs-dpctl functions.
blp at nicira.com
Mon Oct 22 22:54:59 UTC 2012
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 <jpettit at 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
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 at 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
More information about the dev