> Currently, rule_insert() API does not have return value. There are some
possible
> scenarios where rule insertions can fail at run-time even though the
static
> checks during rule_construct() had passed previously.
> Some possible scenarios for failure of rule insertions:
> **) Rule insertions can fail dynamically in Hybrid mode (both Openflow and
> Normal switch functioning coexist) where the CAM space could get suddenly
> filled up by Normal switch functioning and Openflow gets devoid of
> available space.
> **) Some deployments could have separate independent layers for HW rule
> insertions and application layer to interact with OVS. HW layer
> could face any dynamic issue during rule handling which application could
> not have predicted/captured in rule-construction phase.
> Rule-insert errors for bundles are handled too in this pull-request.
>
> Signed-off-by: Aravind Prasad S <raja.avi at gmail.com>

> Which switches does this help?
> Hi Ben,
> These type of errors are possible in actual Hardware implementations
> of OVS. It is possible that ofproto and netdev providers be
> implemented for an actual HW/NPU. Usually, in such cases, in the rule
> construct phase, all the static checks like verifying the qualifiers/
> actions, CAM full checks could be done and the other related
> verifications.
> But during the rule insert phase, it is possible that
> the rule insertion may get failed in HW (runtime errors,
> HW errors and so on). Also, since HW switches may support Hybrid
> mode (coexistence of Normal and Openflow functioning), the
> possibility of this issue could be even more. Further, when
> rule-insertion fails, it results in a stale state where the
> Controller and Switch Flow-DB differ.
> Hence, we need a way to rollback for rule-insert phase also.
> Kindly let me know your views.


Hi Ben/Aaron/All,

In general, this patch will be very useful for all HW implementations
of OVS since the possibility of dynamic rule insertion failures
are high in such deployments. Static checks during
rule-construct phase are not sufficient and future failure predictions
in construct phase may not be possible. Hence, this patch will make
OVS more flexible to handle such failures.

Kindly review and let me know your views.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to