> 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?
ok, i will. YAMAMOTO Takashi > > Thanks, > > Ben. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
