> On Nov 24, 2015, at 10:15 AM, Jarno Rajahalme <ja...@ovn.org> 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:
>>>
>>> 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?
>
parse_ofp_str() already does this:
if (!strcmp(name, "table")) {
error = str_to_u8(value, "table", &fm->table_id);
if (fm->table_id != 0xff) {
*usable_protocols &= OFPUTIL_P_TID;
}
}
Here even “table=0” restricts vanilla OF1.0 out, which I think is the right
thing to do.
So it turns out OF1.0 without table extension is already taken care of by
restricting the choice of protocol.
Jarno
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
