On Fri, Nov 01, 2013 at 03:42:30PM -0700, Jarno Rajahalme wrote:
> 
> On Nov 1, 2013, at 9:43 AM, Ben Pfaff <b...@nicira.com> wrote:
> 
> > Signed-off-by: Ben Pfaff <b...@nicira.com>
> > ---
> > lib/ofp-util.c           |   21 +++++++++++++-
> > tests/learn.at           |    4 +--
> > tests/ofp-print.at       |   12 ++++----
> > tests/ovs-ofctl.at       |   48 +++++++++++++++----------------
> > utilities/ovs-ofctl.8.in |   71 
> > +++++++++++++++++++++++++++++++++++-----------
> > 5 files changed, 106 insertions(+), 50 deletions(-)
> > 
> > diff --git a/lib/ofp-util.c b/lib/ofp-util.c
> > index 3d9efab..e6a9494 100644
> > --- a/lib/ofp-util.c
> > +++ b/lib/ofp-util.c
> > @@ -1530,7 +1530,19 @@ ofputil_decode_flow_mod(struct ofputil_flow_mod *fm,
> >         }
> >         fm->modify_cookie = false;
> >         fm->command = ofm->command;
> > +
> > +        /* Get table ID.
> > +         *
> > +         * OF1.1 entirely forbids table_id == 255.
> > +         * OF1.2+ allows table_id == 255 only for deletes. */
> >         fm->table_id = ofm->table_id;
> > +        if (fm->table_id == 0xff
> 
> I?d rather see ?255? here as well to match the comments.

OK, I made that change.

> > +            && (oh->version == OFP11_VERSION
> > +                || (ofm->command != OFPFC_DELETE &&
> > +                    ofm->command != OFPFC_DELETE_STRICT))) {
> > +            return OFPERR_OFPFMFC_BAD_TABLE_ID;
> > +        }
> > +
> 
> > +For flow dump commands, limits the flows dumped to those in the table
> > +with the given \fInumber\fR between 0 and 254.  If not specified (or if
> > +255 is specified as \fInumber\fR), then flows in all tables are
> > +dumped.
> > +.
> > +.IP
> > +For flow table modification commands, behavior varies based on the
> > +OpenFlow version used to connect to the switch:
> > +.
> > +.RS
> > +.IP "OpenFlow 1.0"
> > +OpenFlow 1.0 does not support \fBtable\fR for modifying flows.
> > +\fBovs\-ofctl\fR will exit with an error if \fBtable\fR (other than
> > +\fBtable=255\fR) is specified for a switch that only supports OpenFlow
> > +1.0.
> > +.IP
> > +In OpenFlow 1.0, the switch chooses the table into which to insert a
> > +new flow.  The Open vSwitch software switch always chooses table 0.
> > +Other Open vSwitch datapaths and other OpenFlow implementations may
> > +choose different tables.
> 
> IMO any implementation should pick the ?input table?, which by
> definition is 0, or no?

The design of the pipeline in OF1.0 was motivated quite differently from
the design in OF1.1 and later versions.  In OF1.0, multiple flow tables
existed only to illustrate the structure of the switch to the
controller.  In particular, at Nicira we had a notion that it would be
useful, for optimization in a software switch, to expose three tables:
one that handled only exact match on all fields (happening first), one
that handled matches on all fields except for the ephemeral port in a
TCP connection (Martin thought this was important but I didn't really
understand the idea so this never got implemented), and one that
implemented wildcards via linear search.  Major changes happened later
that got rid of this idea (among them, we realized that exact match only
would never perform adequately, we figured out a better classifier than
linear, and we found uses for explicitly designated multiple flow
tables) and so the OF1.0 pipeline design pretty much died.  But an OF1.0
switch is still technically allowed to put a flow in whichever flow
table it likes.

I'm going to commit this soon.  We can make the documentation clearer if
you think it's not clear yet.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to