OK.
On Tue, Jul 10, 2018 at 02:58:47PM +0530, Aravind Prasad wrote: > Hi Ben/All, > > If possible, Kindly hold reviewing this patch for now. Expecting an > approval from my Org. Sorry for the inconvenience caused and thanks for the > support. > > Will get back and intimate for the review as soon as possible after the > approval (expecting it to take not more than a week). And thanks again for > understanding. > > Thanks, > Aravind Prasad S > > On Tue, Jul 10, 2018 at 7:06 AM Aravind Prasad <[email protected]> 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. > > > > >> 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 <[email protected]> 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 <[email protected]> > >> > >> 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
