If there is more than one bridge, then it's easy to specify the wrong one
on an ofproto/trace command. Previously, this would produce surprising
results. With this commit, "ofproto/trace" should silently fix up the
problem.
It would be nice to not require the user to specify a bridge at all, but
it's theoretically possible to have more than one backer, in which case we
need some way to distinguish, and a bridge name is as good an identifier
as we have. We could ask the user to specify the datapath_type, I guess,
but that's a less familiar name to most users and it would be a somewhat
gratuitous change in synatx for ofproto/trace.
Bug #15419.
Reported-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
- /* XXX: Since we allow the user to specify an ofproto, it's
- * possible they will specify a different ofproto than the one the
- * port actually belongs too. Ideally we should simply remove the
- * ability to specify the ofproto. */
+ /* The user might have specified the wrong ofproto but within the
+ * same backer. That's OK, ofproto_receive() can find the right
+ * one for us. */
if (ofproto_receive(ofproto->backer, NULL, odp_key.data,
if (ofproto_receive(ofproto->backer, NULL, odp_key.data,
- odp_key.size, &flow, NULL, NULL, NULL,
+ odp_key.size, &flow, NULL, &ofproto, NULL,
&initial_vals)) {
unixctl_command_reply_error(conn, "Invalid flow");
goto exit;
}
&initial_vals)) {
unixctl_command_reply_error(conn, "Invalid flow");
goto exit;
}
+ ds_put_format(&result, "Bridge: %s\n", ofproto->up.name);