niti Rohilla wrote :
>
> 2) Page no. 145 of Openflow Specification 1.5.1.
> The command OFPTFC_REPLACE configures the entire pipeline, and the set of
> flow tables in the pipeline must match the set in the request, or an error
> must be returned (see 7.5.4.14). The capability of all flow tables included
> in the request must be updated. In particular, if the requested
> configuration does not contain an ofp_table_features structure for one or
> more flow tables that the switch supports, these flow tables are to be
> removed from the pipeline if the configuration is successfully set.
>
> Kindly explain the above mentioned paragraph. As per our understanding,
> pipeline is configured based on the flow table entries (using instruction
> goto-table table_id), can you please explain how does OFPTFC_REPLACE
> configures or replaces the entire pipeline associated with tables or we are
> missing something regarding pipeline processing in ovs?
If I were you, I would stay away from pipeline
reconfiguration. Implementing pipeline reconfiguration in OVS would be
a tricky job, detracting you from implementing EXT-306. It's also not
clear how this would integrate with TTPs.
The intent of the API changes in 1.5 was that one would be
able to implement only the minimal subset needed for EXT-306, and
ignore the rest of the API. For example, the spec says :
--------------------------------------
A switch may not support all commands listed above (see 7.5.4.14). For
commands other than OFPTFC_REPLACE, the switch may support a limited
number of flow tables in each request (see 7.5.4.14).
--------------------------------------
----------------------------------
The properties field included in each ofp_table_features structure
must either be empty or must contain exactly one of each of the
ofp_table_feature_prop_type properties
----------------------------------
In other words, I would suggest :
o Don't implement OFPTFC_REPLACE, OFPTFC_ENABLE and
OFPTFC_DISABLE, just return an error for those.
o Only accept a single table in OFPTFC_MODIFY, return an error
for more tables.
o Return an error for any request including table properties,
i.e. only accept an empty table property list. Don't bother even
parsing the properties.
o Only accept to modify the OFPTFF_FIRST_EGRESS flag in the
"features" field, return an error for any attempt to change another
field of the table or another flag.
This should make the implementation simpler... This is still
more code than I would have liked, and mostly just returning various
error codes...
> 3) For a table to be a part of pipleline processing is it necessary to
> configure either of these flags(OFPTFF_INGRESS_TABLE and
> OFPTFF_EGRESS_TABLE). In other words, if none of the flag is set then table
> cannot be part of pipeline processing? Please validate this understanding.
I would suggest to return an error for any attempt to modify
those flags. Just allow to modify OFPTFF_FIRST_EGRESS.
Regards,
Jean
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
