On Tue, Oct 15, 2013 at 10:20:04AM +0900, YAMAMOTO Takashi wrote: > > On Wed, Oct 09, 2013 at 04:49:06PM +0900, YAMAMOTO Takashi wrote: > >> Signed-off-by: YAMAMOTO Takashi <yamam...@valinux.co.jp> > >> + This requires the following. > >> + - Change the default table-miss action (in the absense of table-miss > >> + entry) from packet_in to drop for OF1.3+. Decide what to do if > >> + a switch is configured to support multiple OF versions. > >> + - Distinguish table-miss flow entry and make its packet_in reason > >> + OFPR_NO_MATCH. (OFPR_TABLE_MISS for OF1.4) > >> + - Avoid a table-miss flow entry matching to packets if there are > >> + ordinary flow entries with priority 0 in the table. I.e. The > >> + table-miss flow entry should have lesser effective priority. > > > > I wasn't aware that the table-miss flow entry was supposed to have lower > > effective priority than other flow entries with table 0. Does the text > > of the standard say this or imply this somewhere? > > the standard is obscure as usual. surely there is a room > for different interpretations. > > OF 1.3.2 2 Switch Components (p.8) > > If a matching entry is found, the instructions associated with the > > specific flow entry are executed. If no match is found in a flow > > table, the outcome depends on configuration of the table-miss flow > > entry: > this seems to support lower effective priority behaviour. > > OF 1.3.2 5.3 Matching (p.15) > the figure seems to imply the same. > > OF 1.3.2 5.4 Table-miss (p.16) > > The table-miss flow entry matches packets in the table as expected > > from its set of match fields and priority > this sentence seems to say the opposite. > > is there anything else to look at then the standard pdf? > (ONF-private stuff like openflow.h?)
openflow.h isn't ONF-private, it's just badly published. See http://benpfaff.org/ofh/ for all versions of openflow.h. I participated in the ONF discussions that led to this new "table-miss" flow. I don't remember anything about it being a special "lower-than-lowest" priority flow. Just now, I looked over the most relevant discussion in ticket EXT-108 that created the new behavior, and I don't see anything about this behavior there either. I think this is just a badly worded spec and that we should not do anything different from usual here. Would you mind resubmitting without mentioning this particular behavior? Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
