On Fri, May 25, 2012 at 6:07 AM, Mabry Tyson <[email protected]> wrote: > The OpenFlow 1.0 spec speaks of "a flow table" in Section 2 and the start of > Section 3, but by 3.2 it becomes obvious that the intent was to have > multiple flow tables.
The intent was not so much to have multiple flow tables as a recognition that real hardware *has* multiple flow tables. > Note carefully this says "flow entries", ie elements of the tables. It > seems this is intended to mean "Within a single flow table, packets are > matched ..." I would suggest that clarification in future specs, if not > already done. Later specs address the issue of multiple tables much more explicitly. > So, priorities are relevant only within a flow table. As far as I've seen, > the user can't directly specify which flow rules get put in which tables. Correct, 1.0 does not allow you to specify the table directly (although typically given switch documentation you can be aware of what types of flows will land where). > At the least, I wish the OpenFlow spec allowed for the Flow Mod rules to > specify the minimum table for installing the rule. That is, if I specify > table 2, it would not install it in table 0 or 1, even if it could be. As stated above, this was addressed in later versions of the spec. That being said, you are actually encountering a non-compliant 1.0 switch in the first place, so the behaviour is already broken in subtle ways. > I found that the HP Procurve set the recorded priority of these rules to > 65535, and apparently executed them in hardware. When dpctl displayed the > rules, they showed up with a priority of 65535. The HP software violates the spec - it completely ignores the priority that you give to a flow. There may be ambiguous situations in the 1.0 spec, but this isn't one of them. > So, what do you do if you want to use pyswitch but don't want the rules to > be executed in hardware? I found that removing the TOS from the match was > sufficient to avoid the rule from going into the hardware. (In fact, it got > move to table 2.) The behaviour of the HP datapath is clearly explained in HP documentation, so while it is not standards compliant, it should not be surprising. -- Nick
