> 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....@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. And sorry for re-sending the
review requests many times over. Will avoid in future.

On Fri, Jul 20, 2018 at 10:20 PM, Ben Pfaff <b...@ovn.org> wrote:

On Thu, Jul 12, 2018 at 06:04:47PM +0000, Aravind Prasad S wrote:
> > 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....@gmail.com>
>
> Which switches does this help?
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to