[ovs-dev] Query regarding OF1.5 Egress tables (EXT-306)

[niti Rohilla]

Hi Jean,

Thanks for your reply. Based on your reply please validate our
understanding.

1. From all the commands only OFPTFC_MODIFY needs to be implemented and
only for a single table in a request. This command is used to modify flow
table capabilities and will not modify pipeline processing or any other
ofp_table_features parameter.

So what is the significance of implementing OFPTFC_MODIFY command as the
capabilities (OFPTC_EVICTION, OFPTC_VACANCY_EVENTS) can be modified using
ofp_table_mod messages. When these OFPTC_* flags are modified using
table_mod messages we need to pass ofp_table_mod_prop_eviction and
ofp_table_mod_prop_vacancy properties along with the messages. So how can
we implement capabilities using OFPTFC_MODIFY command?

2. We need to configure only OFPTFF_FIRST_EGRESS flag and all the table
before this will be considered as ingress tables and all the table after
the first egress table will be considered as egress tables.

Thanks and Regards
Niti Rohilla

On Tue, Aug 18, 2015 at 6:08 AM, Jean Tourrilhes <jt at hpl.hp.com> wrote:

> 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
>