Currently, rule_insert() API doesnot 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 not handled in this pull-request. > Will be handled in upcoming pull request.
>> I don't think that ofproto-dpif can ever see such a failure. Are you >> planning to submit an ofproto provider that exercises this behavior? Hi Ben, These type of errors are possible in actual Hardware implementations. It is possible that ofproto and netdev providers could be implemented for a actual HW. Usually, in such cases, in the rule construct phase, all the static checks like verifying the qualifiers and actions 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). Hence, we need a way to rollback for rule-insert phase also. Kindly let me know your views. Thanks, Aravind Prasad S On Tue, Jul 10, 2018 at 3:45 AM Ben Pfaff <b...@ovn.org> wrote: > On Mon, Jul 09, 2018 at 01:02:08PM +0530, Aravind Prasad S wrote: > > Currently, rule_insert() API doesnot 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 not handled in this pull-request. > > Will be handled in upcoming pull request. > > > > Signed-off-by: Aravind Prasad S <raja....@gmail.com> > > I don't think that ofproto-dpif can ever see such a failure. Are you > planning to submit an ofproto provider that exercises this behavior? > > Thanks, > > Ben. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
