On Wed, Aug 01, 2018 at 07:29:06AM +0530, Aravind Prasad 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. > > > >Which switches does this help? > > Hi Ben, > > By "which" switches, you mean to ask to which vendor switches ? > In general, this patch will be very useful for all Switches which > implement OVS for their HW implementations, specifically, > will be useful for Switches which had implemented ofproto > and netdev provider APIs for their respective HW/NPU and > Kernel. And, in case of HW, the possibility of dynamic rule > insertion failures are usually higher. Static checks during > rule-construct phase are not sufficient and predicting > future failure predictions in construct phase may not be possible. > Hence, this patch will make OVS more flexible to handle such > rule insertion failures.
So, basically, you're not willing to name any switches. I'm tired of the vendor secrecy game. They get to see all of our code but they're never willing even to name themselves. Sorry, I'm not going to willingly take this patch. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
