>
>
>On 14 Jan 2022, at 9:58, lic121 wrote:
>
>>>
>>>
>>> On 9 Jan 2022, at 14:44, lic121 wrote:
>>>
>>>> Currently, ipfix creation/delection don't trigger dpif backer
>>>> revalidation. This is not expected, as we need the revalidation
>>>> to commit ipfix into xlate. So that xlate can generate ipfix
>>>> actions.
>>>>
>>>> Signed-off-by: lic121 <lic...@chinatelecom.cn>
>>>> ---
>>>>  ofproto/ofproto-dpif.c | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
>>>> index bc3df8e..1cdef18 100644
>>>> --- a/ofproto/ofproto-dpif.c
>>>> +++ b/ofproto/ofproto-dpif.c
>>>> @@ -2306,6 +2306,7 @@ set_ipfix(
>>>>  {
>>>>      struct ofproto_dpif *ofproto = ofproto_dpif_cast(ofproto_);
>>>>      struct dpif_ipfix *di = ofproto->ipfix;
>>>> +    struct dpif_ipfix *old_ipfix = ofproto->ipfix;
>>>>      bool has_options = bridge_exporter_options || flow_exporters_options;
>>>>      bool new_di = false;
>>>>
>>>> @@ -2335,6 +2336,10 @@ set_ipfix(
>>>>          }
>>>>      }
>>>>
>>>> +    if (old_ipfix != ofproto->ipfix) {
>>>
>>> This only works if ipfix was not configured earlier or disabled, i.e., 
>>> ofproto->ipfix was/is NULL.
>>> If this was your intention, you could just have done “if (new_di || 
>>> !ofproto->ipfix)”.
>>>
>>> However, I think there can also be changed in the configuration that 
>>> requires a revalidate, what do you think? For example, enabling/disabling 
>>> ingress/egress sampling.
>>> In this case dpif_ipfix_set_options() can be changed so it will return true 
>>> if any configuration changes.
>>>
>> Actually, I had ever thought the same thing as you. But at last I didn't do 
>> as that, for 3 reasons:
>> 1. I checked the history commit of ipfix, seems its not active in last 2-3 
>> years. So I guess not so many ovs users are using ipfix feature.
>> 2. In xlate_xbridge_set, the place where checks the change flag, it doesn't 
>> check the ipfix options changes as well.
>>     
>> https://github.com/openvswitch/ovs/blob/eb1ab5357b6f3755f0ef1ee6d341ce24398d3bc1/ofproto/ofproto-dpif-xlate.c#L975-L978
>
>But here it just set the pointer as a reference, it does not take care of 
>acting on configuration changes, or do I miss something?
>
Assume that we checks the ipfix options changes in set_ipfix():
1. set_ipfix(ofproto, new_option,...) {
       if (ofproto->ipfix->options != new_options) {
          ipfix->options = new_options;
          ofproto->backer->need_revalidate = REV_RECONFIGURE;
       }
   }

2. in xlate_xbridge_set, which is under revalidate context.
xlate_xbridge_set() {
    ...
    if (xbridge->ipfix != ipfix) { // here the ipfix options has changed, but 
the "if test" will not aware that
        dpif_ipfix_unref(xbridge->ipfix);
        xbridge->ipfix = dpif_ipfix_ref(ipfix);
    }
}

>> 3. My main patch is the second one in this series, this patch is here 
>> because it breaks two test cases. So I didn't spend muhc time on the ipfix 
>> issue.
>
>See comments on the second patch.
>
>>>> +        ofproto->backer->need_revalidate = REV_RECONFIGURE;
>>>> +    }
>>>> +
>>>>      return 0;
>>>>  }
>>>>
>>>> --
>>>> 1.8.3.1
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> d...@openvswitch.org
>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>>
>
>

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to