On Tue, Nov 24, 2015 at 10:15:57AM -0800, Jarno Rajahalme wrote:
>
> > 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:
> >> 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?
Maybe. I think that "dump-flows" will still print the table numbers for
OF1.0 without the table-id extension, though, so this would cause odd
behavior for what I've considered a reasonable use case of roughly:
ovs-ofctl dump-flows br0 > dump
...
ovs-ofctl replace-flows br0 dump
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
