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

[Aravind Prasad]

> 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.


Hi Ben/All,
Kindly review and let me know your views.

On Tue, Jul 24, 2018 at 5:15 AM, Aravind Prasad <raja.avi at gmail.com> 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.
>
> Hi Ben/All,
>
> Kindly let me know your views.
>
>
> On Sat, Jul 21, 2018 at 9:22 AM, Aravind Prasad <raja.avi at gmail.com>
> 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.
>>
>>
>> On Fri, Jul 20, 2018 at 10:20 PM, Ben Pfaff <blp at ovn.org> 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 <raja.avi at gmail.com>
>>>
>>> Which switches does this help?
>>>
>>
>>
>