> 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/All, Kindly review and let me know your views. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
