> 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 <[email protected]>
> 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. On Tue, Jul 24, 2018 at 5:15 AM, Aravind Prasad <[email protected]> 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 <[email protected]> > > >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 <[email protected]> > 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 <[email protected]> >> >> >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 <[email protected]> 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 <[email protected]> >>> >>> Which switches does this help? >>> >> >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
