> 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. Hi Ben/All, Kindly let me know your views. On Sat, Jul 21, 2018 at 9:22 AM, Aravind Prasad <raja....@gmail.com> 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? > > 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
