[ovs-dev] [PATCH] ofproto: Return error codes for Rule insertions

Ben Pfaff blp at ovn.org
Tue Jul 31 20:57:27 UTC 2018


On Sat, Jul 21, 2018 at 09:22: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 <raja.avi at 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.

Which switches does this help?


More information about the dev mailing list