> On Nov 24, 2015, at 9:40 AM, Jarno Rajahalme <ja...@ovn.org> wrote: > > >> On Nov 24, 2015, at 9:25 AM, Ben Pfaff <b...@ovn.org> wrote: >> >> On Thu, Nov 19, 2015 at 01:33:18PM -0800, Jarno Rajahalme wrote: >>> Currently ovs-ofctl replace-flows and diff-flows commands only support >>> flows in table 0. Extend this to cover all possible tables. >>> >>> Signed-off-by: Jarno Rajahalme <ja...@ovn.org> >> >> There's one oddity that may deserve consideration. It depends on how >> careful we want to be. >> >> OpenFlow 1.0 does not define a way to add a flow to a particular table. >> The switch is responsible for deciding which table is most appropriate >> for a given flow. For example, a switch might have one table that >> supports wildcards and another one that is exact-match (this is in fact >> specifically envisioned by OF1.0 through its insistence that exact-match >> flows have the highest priority). >> >> This means that when talking to an OF1.0 switch, "ovs-ofctl >> replace-flows" (and friends) should ignore the table number. If >> a flow on the switch is in table 1, but the input file says it is in >> table 0 (probably because it doesn't specify a table at all), ovs-ofctl >> should do nothing, because that's the desired state. >> > > So for an OF1.0 switch without the Table ID extension we should ignore table > numbers both ways, when reading from the file and when reading from the > switch, essentially pretend that there is only one table? > >> However, for practically forever, OVS has had special extensions to >> allow control over the table in which a flow lives. This means that if >> ovs-ofctl is talking to OVS, even in OpenFlow 1.0, it should place flows >> where the user requested and should not ignore the table numbers. >> >> This distinction is reflected through ofputil_protocol values. If a >> switch supports OFPUTIL_P_OF10_STD_TID or OFPUTIL_P_OF10_NXM_TID, then >> ovs-ofctl can place flows arbitrarily; if it only supports >> OFPUTIL_P_OF10_STD (or, theoretically, only OFPUTIL_P_OF10_NXM), then it >> is just a plain OF1.0 switch and all of the tables should be treated >> alike. >> >> OF1.1+ all support placing flows where the user requests. >> >> It's probably not too hard to support this, and possibly it is >> worthwhile. >>
IMO this could be cleaner if the choice of protocol is driven by the input file. If the file has any flow with a non-zero or non-all table number, then we restrict the choice of protocols to ones that support multiple tables. Sounds reasonable? Jarno >> What do you think? > > I’ll take a stab at it, assuming the above, > > Jarno > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
