Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Dumitru Ceara]

On 4/4/24 21:23, Ihar Hrachyshka wrote:
> On Thu, Apr 4, 2024 at 6:06 AM Dumitru Ceara  wrote:
> 
>> On 4/3/24 22:05, Vladislav Odintsov wrote:
>>> re-sending email because ovs list rejected previous its content for some
>> reason:
>>>
>>> Hi Ihar,
>>>
>>
>> Hi Vladislav, Ihar,
>>
>>> thanks for your quick reaction!
>>> I didn’t see mentioned thread, but I think that it is not safe enough to
>> have automatic detection of this scenario here.
>>>
>>> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must
>> configure also either GENEVE and/or STT encap(s) for HV chassis.
>>>
>>> So, detection could be implemented like this:
>>> Check all non-VTEP chassis' encaps and find "effective encap" for each
>> of them. If we detect at least one chassis with "effective encap" == vxlan,
>> then enable vxlan mode. Normal mode otherwise.
>>> "effective encap" means that for 'vxlan,geneve,stt' encaps effective is
>> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
>>> Such behavior was my first idea.
>>>
>>> But I decided that there possible flapping of modes if there is a
>> problem/bug in deployment tooling and it is enough to have only one chassis
>> with wrong encap set to affect vxlan mode for entire OVN cluster. Such mode
>> flapping can result in problems with tunnel ids allocation.
>>
>> These are valid points.
>>
>>
> This is a valid concern. Should it perhaps be handled in the general case
> then? Meaning: calculate the max tunid once and store it in db? (I am
> thinking that maybe recalculating the max_tunid on every engine cycle - or
> on every controller restart - is unsafe?)
> 

OTOH, this is a rather "static" characteristic of the cluster and the
CMS can easily know what kind of encapsulation it's configuring OVN to use.

I think I'd keep it simple (for OVN).

> 
>>> So it seems that to have an option that statically sets vxlan mode is
>> more resilient.
>>
>> In general we try to avoid new config knobs.
>> .
>>> What do you think?
>>>
>>
>> But in this case it make actually be easier if we offload the work of
>> determining vxlan-mode to the CMS.
>>
>>>
 On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:

 Thank you Vladislav.

 FYI it was reported in the past in
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html
>> but fell through cracks then. Thanks for picking it up!

 In your patch, you introduce a new config option to disable the
>> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can
>> automatically detect this scenario by ignoring the chassis that are VTEP
>> from consideration? I believe ovn-controller-vtep sets `is-vtep` in
>> other_config, so - would it work if we modify is_vxlan_mode to consider it
>> too?

 Thanks again for looking into this.
 Ihar

 On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov > > wrote:
> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
> for available tunnel IDs because of lack of space in VXLAN VNI.
> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> and 2047 logical switch ports per datapath.
>
> Prior to this patch vxlan mode was enabled automatically if at least
>> one
> chassis had encap of vxlan type.  In scenarios where one want to use
>> VXLAN
> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>
> This patch adds support for explicit disabling of vxlan mode via
> Northbound database.
>
> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>
> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath
>> bindings")
> Signed-off-by: Vladislav Odintsov > odiv...@gmail.com>>
> ---
>  northd/en-global-config.c |  9 +++-
>  northd/northd.c   | 90 ++-
>  northd/northd.h   |  6 ++-
>  ovn-nb.xml| 12 ++
>  tests/ovn-northd.at    | 29 +
>  5 files changed, 94 insertions(+), 52 deletions(-)
>
> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
> index 34e393b33..9310c4575 100644
> --- a/northd/en-global-config.c
> +++ b/northd/en-global-config.c
> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node ,
>> void *data)
>   config_data->svc_monitor_mac);
>  }
>
> -char *max_tunid = xasprintf("%d",
> -get_ovn_max_dp_key_local(sbrec_chassis_table));
> +init_vxlan_mode(>options, sbrec_chassis_table);
> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>  smap_replace(options, "max_tunid", max_tunid);
>  free(max_tunid);
>
> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct
>> nbrec_nb_global *nb,
>  return true;
>  }
>
> +  

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Ihar Hrachyshka]

On Wed, Apr 3, 2024 at 3:01 PM Vladislav Odintsov  wrote:

> Hi Ihar,
>
> thanks for your quick reaction!
> I didn’t see mentioned thread, but think that it is not safe enough to
> have automatic detection of this scenario here.
> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must
> configure also either GENEVE and/or STT encap(s) for HV chassis.
> So, detection could be implemented like this:
> Check all non-VTEP chassis’ encaps and find ‘effective’ encap for each of
> them. If we detect at least one chassis with ‘effective’ encap == vxlan,
> enable vxlan mode. Normal mode otherwise.
> ‘effective encap’ means that for ‘vxlan,geneve,stt’ encaps effective is
> geneve, for ‘vxlan,stt’ -> stt, for ‘vxlan’ -> vxlan.
> Such behavior was my first idea.
>
> But I decided that there possible flapping of modes if there is a
> problem/bug in deployment tooling and it is enough to have only one chassis
> with wrong encap set to affect vxlan mode for entire OVN cluster. Such mode
> flapping can result in problems with tunnel ids allocation.
> So it seems that to have an option that statically sets vxlan mode is more
> resilient.
> What do you think?
>

To close the loop here, I've looked into is-vtep auto-detection myself and
realized that Encaps do not reflect the *peer* chassis, so it's not as
trivial to detect the mode automatically. One would have to iterate over
port bindings and check that all "vxlan peer chassis" hosts only type=vtep
bindings... I agree that a config knob here is the way to go.


>
> regards,
> Vladislav Odintsov
>
> On 3 Apr 2024, at 20:44, Ihar Hrachyshka  wrote:
>
> 
> Thank you Vladislav.
>
> FYI it was reported in the past in
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html
> but fell through cracks then. Thanks for picking it up!
>
> In your patch, you introduce a new config option to disable the
> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can
> automatically detect this scenario by ignoring the chassis that are VTEP
> from consideration? I believe ovn-controller-vtep sets `is-vtep` in
> other_config, so - would it work if we modify is_vxlan_mode to consider it
> too?
>
> Thanks again for looking into this.
> Ihar
>
> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov 
> wrote:
>
>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
>> for available tunnel IDs because of lack of space in VXLAN VNI.
>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
>> and 2047 logical switch ports per datapath.
>>
>> Prior to this patch vxlan mode was enabled automatically if at least one
>> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>>
>> This patch adds support for explicit disabling of vxlan mode via
>> Northbound database.
>>
>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>>
>> CC: Ihar Hrachyshka 
>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
>> Signed-off-by: Vladislav Odintsov 
>> ---
>>  northd/en-global-config.c |  9 +++-
>>  northd/northd.c   | 90 ++-
>>  northd/northd.h   |  6 ++-
>>  ovn-nb.xml| 12 ++
>>  tests/ovn-northd.at   | 29 +
>>  5 files changed, 94 insertions(+), 52 deletions(-)
>>
>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
>> index 34e393b33..9310c4575 100644
>> --- a/northd/en-global-config.c
>> +++ b/northd/en-global-config.c
>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void
>> *data)
>>   config_data->svc_monitor_mac);
>>  }
>>
>> -char *max_tunid = xasprintf("%d",
>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
>> +init_vxlan_mode(>options, sbrec_chassis_table);
>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>>  smap_replace(options, "max_tunid", max_tunid);
>>  free(max_tunid);
>>
>> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct
>> nbrec_nb_global *nb,
>>  return true;
>>  }
>>
>> +if (config_out_of_sync(>options, _data->nb_options,
>> +   "disable_vxlan_mode", false)) {
>> +return true;
>> +}
>> +
>>  return false;
>>  }
>>
>> diff --git a/northd/northd.c b/northd/northd.c
>> index c568f6360..859b233e8 100644
>> --- a/northd/northd.c
>> +++ b/northd/northd.c
>> @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
>>   */
>>  static bool default_acl_drop;
>>
>> +/* If this option is 'true' northd will use limited 24-bit space for
>> datapath
>> + * and ports tunnel key allocation (12 bits for each instead of default
>> 16). */
>> +static bool vxlan_mode;
>> +
>>  #define MAX_OVN_TAGS 4096
>>
>>
>> @@ -875,24 +879,31 @@ join_datapaths(const struct
>> nbrec_logical_switch_table *nbrec_ls_table,
>>  }
>>  }
>>
>> -static bool
>> 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Ihar Hrachyshka]

On Thu, Apr 4, 2024 at 6:06 AM Dumitru Ceara  wrote:

> On 4/3/24 22:05, Vladislav Odintsov wrote:
> > re-sending email because ovs list rejected previous its content for some
> reason:
> >
> > Hi Ihar,
> >
>
> Hi Vladislav, Ihar,
>
> > thanks for your quick reaction!
> > I didn’t see mentioned thread, but I think that it is not safe enough to
> have automatic detection of this scenario here.
> >
> > Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must
> configure also either GENEVE and/or STT encap(s) for HV chassis.
> >
> > So, detection could be implemented like this:
> > Check all non-VTEP chassis' encaps and find "effective encap" for each
> of them. If we detect at least one chassis with "effective encap" == vxlan,
> then enable vxlan mode. Normal mode otherwise.
> > "effective encap" means that for 'vxlan,geneve,stt' encaps effective is
> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
> > Such behavior was my first idea.
> >
> > But I decided that there possible flapping of modes if there is a
> problem/bug in deployment tooling and it is enough to have only one chassis
> with wrong encap set to affect vxlan mode for entire OVN cluster. Such mode
> flapping can result in problems with tunnel ids allocation.
>
> These are valid points.
>
>
This is a valid concern. Should it perhaps be handled in the general case
then? Meaning: calculate the max tunid once and store it in db? (I am
thinking that maybe recalculating the max_tunid on every engine cycle - or
on every controller restart - is unsafe?)


> > So it seems that to have an option that statically sets vxlan mode is
> more resilient.
>
> In general we try to avoid new config knobs.
> .
> > What do you think?
> >
>
> But in this case it make actually be easier if we offload the work of
> determining vxlan-mode to the CMS.
>
> >
> >> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
> >>
> >> Thank you Vladislav.
> >>
> >> FYI it was reported in the past in
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html
> but fell through cracks then. Thanks for picking it up!
> >>
> >> In your patch, you introduce a new config option to disable the
> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can
> automatically detect this scenario by ignoring the chassis that are VTEP
> from consideration? I believe ovn-controller-vtep sets `is-vtep` in
> other_config, so - would it work if we modify is_vxlan_mode to consider it
> too?
> >>
> >> Thanks again for looking into this.
> >> Ihar
> >>
> >> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov  > wrote:
> >>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
> >>> for available tunnel IDs because of lack of space in VXLAN VNI.
> >>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> >>> and 2047 logical switch ports per datapath.
> >>>
> >>> Prior to this patch vxlan mode was enabled automatically if at least
> one
> >>> chassis had encap of vxlan type.  In scenarios where one want to use
> VXLAN
> >>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
> >>>
> >>> This patch adds support for explicit disabling of vxlan mode via
> >>> Northbound database.
> >>>
> >>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
> >>>
> >>> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
> >>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath
> bindings")
> >>> Signed-off-by: Vladislav Odintsov  odiv...@gmail.com>>
> >>> ---
> >>>  northd/en-global-config.c |  9 +++-
> >>>  northd/northd.c   | 90 ++-
> >>>  northd/northd.h   |  6 ++-
> >>>  ovn-nb.xml| 12 ++
> >>>  tests/ovn-northd.at    | 29 +
> >>>  5 files changed, 94 insertions(+), 52 deletions(-)
> >>>
> >>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
> >>> index 34e393b33..9310c4575 100644
> >>> --- a/northd/en-global-config.c
> >>> +++ b/northd/en-global-config.c
> >>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node ,
> void *data)
> >>>   config_data->svc_monitor_mac);
> >>>  }
> >>>
> >>> -char *max_tunid = xasprintf("%d",
> >>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
> >>> +init_vxlan_mode(>options, sbrec_chassis_table);
> >>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
> >>>  smap_replace(options, "max_tunid", max_tunid);
> >>>  free(max_tunid);
> >>>
> >>> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct
> nbrec_nb_global *nb,
> >>>  return true;
> >>>  }
> >>>
> >>> +if (config_out_of_sync(>options, _data->nb_options,
> >>> +   "disable_vxlan_mode", false)) {
> >>> +return true;
> >>> +}
> >>> +
> >>>  return false;
> >>>  }
> >>>
> >>> diff --git a/northd/northd.c b/northd/northd.c
> >>> index 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Vladislav Odintsov]

I’ve sent v2:
https://patchwork.ozlabs.org/project/ovn/patch/20240404160628.970615-1-odiv...@gmail.com/

> On 4 Apr 2024, at 18:27, Dumitru Ceara  wrote:
> 
> On 4/4/24 14:38, Vladislav Odintsov wrote:
>> *Patch [1] is 
>> https://patchwork.ozlabs.org/project/ovn/patch/20240401121510.758326-1-odiv...@gmail.com/
>> 
>>> On 4 Apr 2024, at 15:33, Vladislav Odintsov  wrote:
>>> 
>>> Hi Dumitru,
>>> 
>>> thanks for your attention on this!
>>> 
 On 4 Apr 2024, at 13:06, Dumitru Ceara  wrote:
 
 On 4/3/24 22:05, Vladislav Odintsov wrote:
> re-sending email because ovs list rejected previous its content for some 
> reason:
> 
> Hi Ihar,
> 
 
 Hi Vladislav, Ihar,
 
> thanks for your quick reaction!
> I didn’t see mentioned thread, but I think that it is not safe enough to 
> have automatic detection of this scenario here.
> 
> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must 
> configure also either GENEVE and/or STT encap(s) for HV chassis.
> 
> So, detection could be implemented like this:
> Check all non-VTEP chassis' encaps and find "effective encap" for each of 
> them. If we detect at least one chassis with "effective encap" == vxlan, 
> then enable vxlan mode. Normal mode otherwise.
> "effective encap" means that for 'vxlan,geneve,stt' encaps effective is 
> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
> Such behavior was my first idea.
> 
> But I decided that there possible flapping of modes if there is a 
> problem/bug in deployment tooling and it is enough to have only one 
> chassis with wrong encap set to affect vxlan mode for entire OVN cluster. 
> Such mode flapping can result in problems with tunnel ids allocation.
 
 These are valid points.
 
> So it seems that to have an option that statically sets vxlan mode is 
> more resilient.
 
 In general we try to avoid new config knobs.
 .
> What do you think?
> 
 
 But in this case it make actually be easier if we offload the work of
 determining vxlan-mode to the CMS.
 
> 
>> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
>> 
>> Thank you Vladislav.
>> 
>> FYI it was reported in the past in 
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html 
>> but fell through cracks then. Thanks for picking it up!
>> 
>> In your patch, you introduce a new config option to disable the 
>> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can 
>> automatically detect this scenario by ignoring the chassis that are VTEP 
>> from consideration? I believe ovn-controller-vtep sets `is-vtep` in 
>> other_config, so - would it work if we modify is_vxlan_mode to consider 
>> it too?
>> 
>> Thanks again for looking into this.
>> Ihar
>> 
>> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov > > wrote:
>>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
>>> for available tunnel IDs because of lack of space in VXLAN VNI.
>>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
>>> and 2047 logical switch ports per datapath.
>>> 
>>> Prior to this patch vxlan mode was enabled automatically if at least one
>>> chassis had encap of vxlan type.  In scenarios where one want to use 
>>> VXLAN
>>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>>> 
>>> This patch adds support for explicit disabling of vxlan mode via
>>> Northbound database.
>>> 
>>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>>> 
>>> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
>>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
>>> Signed-off-by: Vladislav Odintsov >> >
>>> ---
>>> northd/en-global-config.c |  9 +++-
>>> northd/northd.c   | 90 ++-
>>> northd/northd.h   |  6 ++-
>>> ovn-nb.xml| 12 ++
>>> tests/ovn-northd.at    | 29 +
>>> 5 files changed, 94 insertions(+), 52 deletions(-)
>>> 
>>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
>>> index 34e393b33..9310c4575 100644
>>> --- a/northd/en-global-config.c
>>> +++ b/northd/en-global-config.c
>>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , 
>>> void *data)
>>>config_data->svc_monitor_mac);
>>>   }
>>> 
>>> -char *max_tunid = xasprintf("%d",
>>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
>>> +init_vxlan_mode(>options, sbrec_chassis_table);
>>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>>>   

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Dumitru Ceara]

On 4/4/24 14:38, Vladislav Odintsov wrote:
> *Patch [1] is 
> https://patchwork.ozlabs.org/project/ovn/patch/20240401121510.758326-1-odiv...@gmail.com/
> 
>> On 4 Apr 2024, at 15:33, Vladislav Odintsov  wrote:
>>
>> Hi Dumitru,
>>
>> thanks for your attention on this!
>>
>>> On 4 Apr 2024, at 13:06, Dumitru Ceara  wrote:
>>>
>>> On 4/3/24 22:05, Vladislav Odintsov wrote:
 re-sending email because ovs list rejected previous its content for some 
 reason:

 Hi Ihar,

>>>
>>> Hi Vladislav, Ihar,
>>>
 thanks for your quick reaction!
 I didn’t see mentioned thread, but I think that it is not safe enough to 
 have automatic detection of this scenario here.

 Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must 
 configure also either GENEVE and/or STT encap(s) for HV chassis.

 So, detection could be implemented like this:
 Check all non-VTEP chassis' encaps and find "effective encap" for each of 
 them. If we detect at least one chassis with "effective encap" == vxlan, 
 then enable vxlan mode. Normal mode otherwise.
 "effective encap" means that for 'vxlan,geneve,stt' encaps effective is 
 geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
 Such behavior was my first idea.

 But I decided that there possible flapping of modes if there is a 
 problem/bug in deployment tooling and it is enough to have only one 
 chassis with wrong encap set to affect vxlan mode for entire OVN cluster. 
 Such mode flapping can result in problems with tunnel ids allocation.
>>>
>>> These are valid points.
>>>
 So it seems that to have an option that statically sets vxlan mode is more 
 resilient.
>>>
>>> In general we try to avoid new config knobs.
>>> .
 What do you think?

>>>
>>> But in this case it make actually be easier if we offload the work of
>>> determining vxlan-mode to the CMS.
>>>

> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
>
> Thank you Vladislav.
>
> FYI it was reported in the past in 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html 
> but fell through cracks then. Thanks for picking it up!
>
> In your patch, you introduce a new config option to disable the 
> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can 
> automatically detect this scenario by ignoring the chassis that are VTEP 
> from consideration? I believe ovn-controller-vtep sets `is-vtep` in 
> other_config, so - would it work if we modify is_vxlan_mode to consider 
> it too?
>
> Thanks again for looking into this.
> Ihar
>
> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov  > wrote:
>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
>> for available tunnel IDs because of lack of space in VXLAN VNI.
>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
>> and 2047 logical switch ports per datapath.
>>
>> Prior to this patch vxlan mode was enabled automatically if at least one
>> chassis had encap of vxlan type.  In scenarios where one want to use 
>> VXLAN
>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>>
>> This patch adds support for explicit disabling of vxlan mode via
>> Northbound database.
>>
>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>>
>> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
>> Signed-off-by: Vladislav Odintsov > >
>> ---
>> northd/en-global-config.c |  9 +++-
>> northd/northd.c   | 90 ++-
>> northd/northd.h   |  6 ++-
>> ovn-nb.xml| 12 ++
>> tests/ovn-northd.at    | 29 +
>> 5 files changed, 94 insertions(+), 52 deletions(-)
>>
>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
>> index 34e393b33..9310c4575 100644
>> --- a/northd/en-global-config.c
>> +++ b/northd/en-global-config.c
>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
>> *data)
>> config_data->svc_monitor_mac);
>>}
>>
>> -char *max_tunid = xasprintf("%d",
>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
>> +init_vxlan_mode(>options, sbrec_chassis_table);
>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>>smap_replace(options, "max_tunid", max_tunid);
>>free(max_tunid);
>>
>> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
>> nbrec_nb_global *nb,
>>return true;
>>}
>>
>> +if (config_out_of_sync(>options, _data->nb_options,
>> +

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Vladislav Odintsov]

*Patch [1] is 
https://patchwork.ozlabs.org/project/ovn/patch/20240401121510.758326-1-odiv...@gmail.com/

> On 4 Apr 2024, at 15:33, Vladislav Odintsov  wrote:
> 
> Hi Dumitru,
> 
> thanks for your attention on this!
> 
>> On 4 Apr 2024, at 13:06, Dumitru Ceara  wrote:
>> 
>> On 4/3/24 22:05, Vladislav Odintsov wrote:
>>> re-sending email because ovs list rejected previous its content for some 
>>> reason:
>>> 
>>> Hi Ihar,
>>> 
>> 
>> Hi Vladislav, Ihar,
>> 
>>> thanks for your quick reaction!
>>> I didn’t see mentioned thread, but I think that it is not safe enough to 
>>> have automatic detection of this scenario here.
>>> 
>>> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must 
>>> configure also either GENEVE and/or STT encap(s) for HV chassis.
>>> 
>>> So, detection could be implemented like this:
>>> Check all non-VTEP chassis' encaps and find "effective encap" for each of 
>>> them. If we detect at least one chassis with "effective encap" == vxlan, 
>>> then enable vxlan mode. Normal mode otherwise.
>>> "effective encap" means that for 'vxlan,geneve,stt' encaps effective is 
>>> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
>>> Such behavior was my first idea.
>>> 
>>> But I decided that there possible flapping of modes if there is a 
>>> problem/bug in deployment tooling and it is enough to have only one chassis 
>>> with wrong encap set to affect vxlan mode for entire OVN cluster. Such mode 
>>> flapping can result in problems with tunnel ids allocation.
>> 
>> These are valid points.
>> 
>>> So it seems that to have an option that statically sets vxlan mode is more 
>>> resilient.
>> 
>> In general we try to avoid new config knobs.
>> .
>>> What do you think?
>>> 
>> 
>> But in this case it make actually be easier if we offload the work of
>> determining vxlan-mode to the CMS.
>> 
>>> 
 On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
 
 Thank you Vladislav.
 
 FYI it was reported in the past in 
 https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html 
 but fell through cracks then. Thanks for picking it up!
 
 In your patch, you introduce a new config option to disable the 
 'vxlan-mode' behavior. This will definitely work. But I wonder if we can 
 automatically detect this scenario by ignoring the chassis that are VTEP 
 from consideration? I believe ovn-controller-vtep sets `is-vtep` in 
 other_config, so - would it work if we modify is_vxlan_mode to consider it 
 too?
 
 Thanks again for looking into this.
 Ihar
 
 On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov >>> > wrote:
> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
> for available tunnel IDs because of lack of space in VXLAN VNI.
> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> and 2047 logical switch ports per datapath.
> 
> Prior to this patch vxlan mode was enabled automatically if at least one
> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
> only for HW VTEP (RAMP) switch, such limitation makes no sence.
> 
> This patch adds support for explicit disabling of vxlan mode via
> Northbound database.
> 
> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
> 
> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
> Signed-off-by: Vladislav Odintsov  >
> ---
> northd/en-global-config.c |  9 +++-
> northd/northd.c   | 90 ++-
> northd/northd.h   |  6 ++-
> ovn-nb.xml| 12 ++
> tests/ovn-northd.at    | 29 +
> 5 files changed, 94 insertions(+), 52 deletions(-)
> 
> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
> index 34e393b33..9310c4575 100644
> --- a/northd/en-global-config.c
> +++ b/northd/en-global-config.c
> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
> *data)
> config_data->svc_monitor_mac);
>}
> 
> -char *max_tunid = xasprintf("%d",
> -get_ovn_max_dp_key_local(sbrec_chassis_table));
> +init_vxlan_mode(>options, sbrec_chassis_table);
> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>smap_replace(options, "max_tunid", max_tunid);
>free(max_tunid);
> 
> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
> nbrec_nb_global *nb,
>return true;
>}
> 
> +if (config_out_of_sync(>options, _data->nb_options,
> +   "disable_vxlan_mode", false)) {
> +return true;
> +}
> +
>return false;
> }
> 
> diff --git 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Vladislav Odintsov]

Hi Dumitru,

thanks for your attention on this!

> On 4 Apr 2024, at 13:06, Dumitru Ceara  wrote:
> 
> On 4/3/24 22:05, Vladislav Odintsov wrote:
>> re-sending email because ovs list rejected previous its content for some 
>> reason:
>> 
>> Hi Ihar,
>> 
> 
> Hi Vladislav, Ihar,
> 
>> thanks for your quick reaction!
>> I didn’t see mentioned thread, but I think that it is not safe enough to 
>> have automatic detection of this scenario here.
>> 
>> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must 
>> configure also either GENEVE and/or STT encap(s) for HV chassis.
>> 
>> So, detection could be implemented like this:
>> Check all non-VTEP chassis' encaps and find "effective encap" for each of 
>> them. If we detect at least one chassis with "effective encap" == vxlan, 
>> then enable vxlan mode. Normal mode otherwise.
>> "effective encap" means that for 'vxlan,geneve,stt' encaps effective is 
>> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
>> Such behavior was my first idea.
>> 
>> But I decided that there possible flapping of modes if there is a 
>> problem/bug in deployment tooling and it is enough to have only one chassis 
>> with wrong encap set to affect vxlan mode for entire OVN cluster. Such mode 
>> flapping can result in problems with tunnel ids allocation.
> 
> These are valid points.
> 
>> So it seems that to have an option that statically sets vxlan mode is more 
>> resilient.
> 
> In general we try to avoid new config knobs.
> .
>> What do you think?
>> 
> 
> But in this case it make actually be easier if we offload the work of
> determining vxlan-mode to the CMS.
> 
>> 
>>> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
>>> 
>>> Thank you Vladislav.
>>> 
>>> FYI it was reported in the past in 
>>> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html 
>>> but fell through cracks then. Thanks for picking it up!
>>> 
>>> In your patch, you introduce a new config option to disable the 
>>> 'vxlan-mode' behavior. This will definitely work. But I wonder if we can 
>>> automatically detect this scenario by ignoring the chassis that are VTEP 
>>> from consideration? I believe ovn-controller-vtep sets `is-vtep` in 
>>> other_config, so - would it work if we modify is_vxlan_mode to consider it 
>>> too?
>>> 
>>> Thanks again for looking into this.
>>> Ihar
>>> 
>>> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov >> > wrote:
 Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
 for available tunnel IDs because of lack of space in VXLAN VNI.
 In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
 and 2047 logical switch ports per datapath.
 
 Prior to this patch vxlan mode was enabled automatically if at least one
 chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
 only for HW VTEP (RAMP) switch, such limitation makes no sence.
 
 This patch adds support for explicit disabling of vxlan mode via
 Northbound database.
 
 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
 
 CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
 Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
 Signed-off-by: Vladislav Odintsov >>> >
 ---
 northd/en-global-config.c |  9 +++-
 northd/northd.c   | 90 ++-
 northd/northd.h   |  6 ++-
 ovn-nb.xml| 12 ++
 tests/ovn-northd.at    | 29 +
 5 files changed, 94 insertions(+), 52 deletions(-)
 
 diff --git a/northd/en-global-config.c b/northd/en-global-config.c
 index 34e393b33..9310c4575 100644
 --- a/northd/en-global-config.c
 +++ b/northd/en-global-config.c
 @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
 *data)
  config_data->svc_monitor_mac);
 }
 
 -char *max_tunid = xasprintf("%d",
 -get_ovn_max_dp_key_local(sbrec_chassis_table));
 +init_vxlan_mode(>options, sbrec_chassis_table);
 +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
 smap_replace(options, "max_tunid", max_tunid);
 free(max_tunid);
 
 @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
 nbrec_nb_global *nb,
 return true;
 }
 
 +if (config_out_of_sync(>options, _data->nb_options,
 +   "disable_vxlan_mode", false)) {
 +return true;
 +}
 +
 return false;
 }
 
 diff --git a/northd/northd.c b/northd/northd.c
 index c568f6360..859b233e8 100644
 --- a/northd/northd.c
 +++ b/northd/northd.c
 @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
  */
 static bool default_acl_drop;
 
 +/* If this option is 'true' northd will 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Dumitru Ceara]

On 4/3/24 22:05, Vladislav Odintsov wrote:
> re-sending email because ovs list rejected previous its content for some 
> reason:
> 
> Hi Ihar,
> 

Hi Vladislav, Ihar,

> thanks for your quick reaction!
> I didn’t see mentioned thread, but I think that it is not safe enough to have 
> automatic detection of this scenario here.
> 
> Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must 
> configure also either GENEVE and/or STT encap(s) for HV chassis.
> 
> So, detection could be implemented like this:
> Check all non-VTEP chassis' encaps and find "effective encap" for each of 
> them. If we detect at least one chassis with "effective encap" == vxlan, then 
> enable vxlan mode. Normal mode otherwise.
> "effective encap" means that for 'vxlan,geneve,stt' encaps effective is 
> geneve, for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
> Such behavior was my first idea.
> 
> But I decided that there possible flapping of modes if there is a problem/bug 
> in deployment tooling and it is enough to have only one chassis with wrong 
> encap set to affect vxlan mode for entire OVN cluster. Such mode flapping can 
> result in problems with tunnel ids allocation.

These are valid points.

> So it seems that to have an option that statically sets vxlan mode is more 
> resilient.

In general we try to avoid new config knobs.
.
> What do you think?
> 

But in this case it make actually be easier if we offload the work of
determining vxlan-mode to the CMS.

> 
>> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
>>
>> Thank you Vladislav.
>>
>> FYI it was reported in the past in 
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html but 
>> fell through cracks then. Thanks for picking it up!
>>
>> In your patch, you introduce a new config option to disable the 'vxlan-mode' 
>> behavior. This will definitely work. But I wonder if we can automatically 
>> detect this scenario by ignoring the chassis that are VTEP from 
>> consideration? I believe ovn-controller-vtep sets `is-vtep` in other_config, 
>> so - would it work if we modify is_vxlan_mode to consider it too?
>>
>> Thanks again for looking into this.
>> Ihar
>>
>> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov > > wrote:
>>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
>>> for available tunnel IDs because of lack of space in VXLAN VNI.
>>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
>>> and 2047 logical switch ports per datapath.
>>>
>>> Prior to this patch vxlan mode was enabled automatically if at least one
>>> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
>>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>>>
>>> This patch adds support for explicit disabling of vxlan mode via
>>> Northbound database.
>>>
>>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>>>
>>> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
>>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
>>> Signed-off-by: Vladislav Odintsov >> >
>>> ---
>>>  northd/en-global-config.c |  9 +++-
>>>  northd/northd.c   | 90 ++-
>>>  northd/northd.h   |  6 ++-
>>>  ovn-nb.xml| 12 ++
>>>  tests/ovn-northd.at    | 29 +
>>>  5 files changed, 94 insertions(+), 52 deletions(-)
>>>
>>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
>>> index 34e393b33..9310c4575 100644
>>> --- a/northd/en-global-config.c
>>> +++ b/northd/en-global-config.c
>>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
>>> *data)
>>>   config_data->svc_monitor_mac);
>>>  }
>>>
>>> -char *max_tunid = xasprintf("%d",
>>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
>>> +init_vxlan_mode(>options, sbrec_chassis_table);
>>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>>>  smap_replace(options, "max_tunid", max_tunid);
>>>  free(max_tunid);
>>>
>>> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
>>> nbrec_nb_global *nb,
>>>  return true;
>>>  }
>>>
>>> +if (config_out_of_sync(>options, _data->nb_options,
>>> +   "disable_vxlan_mode", false)) {
>>> +return true;
>>> +}
>>> +
>>>  return false;
>>>  }
>>>
>>> diff --git a/northd/northd.c b/northd/northd.c
>>> index c568f6360..859b233e8 100644
>>> --- a/northd/northd.c
>>> +++ b/northd/northd.c
>>> @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
>>>   */
>>>  static bool default_acl_drop;
>>>
>>> +/* If this option is 'true' northd will use limited 24-bit space for 
>>> datapath
>>> + * and ports tunnel key allocation (12 bits for each instead of default 
>>> 16). */
>>> +static bool vxlan_mode;
>>> +
>>>  #define MAX_OVN_TAGS 4096
>>>
>>>
>>> @@ -875,24 +879,31 @@ 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Vladislav Odintsov]

re-sending email because ovs list rejected previous its content for some reason:

Hi Ihar,

thanks for your quick reaction!
I didn’t see mentioned thread, but I think that it is not safe enough to have 
automatic detection of this scenario here.

Imagine: for VXLAN with HW VTEP scenario besides VXLAN encap one must configure 
also either GENEVE and/or STT encap(s) for HV chassis.

So, detection could be implemented like this:
Check all non-VTEP chassis' encaps and find "effective encap" for each of them. 
If we detect at least one chassis with "effective encap" == vxlan, then enable 
vxlan mode. Normal mode otherwise.
"effective encap" means that for 'vxlan,geneve,stt' encaps effective is geneve, 
for 'vxlan,stt' -> stt, for 'vxlan' -> vxlan.
Such behavior was my first idea.

But I decided that there possible flapping of modes if there is a problem/bug 
in deployment tooling and it is enough to have only one chassis with wrong 
encap set to affect vxlan mode for entire OVN cluster. Such mode flapping can 
result in problems with tunnel ids allocation.
So it seems that to have an option that statically sets vxlan mode is more 
resilient.
What do you think?


> On 3 Apr 2024, at 20:43, Ihar Hrachyshka  wrote:
> 
> Thank you Vladislav.
> 
> FYI it was reported in the past in 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html but 
> fell through cracks then. Thanks for picking it up!
> 
> In your patch, you introduce a new config option to disable the 'vxlan-mode' 
> behavior. This will definitely work. But I wonder if we can automatically 
> detect this scenario by ignoring the chassis that are VTEP from 
> consideration? I believe ovn-controller-vtep sets `is-vtep` in other_config, 
> so - would it work if we modify is_vxlan_mode to consider it too?
> 
> Thanks again for looking into this.
> Ihar
> 
> On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov  > wrote:
>> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
>> for available tunnel IDs because of lack of space in VXLAN VNI.
>> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
>> and 2047 logical switch ports per datapath.
>> 
>> Prior to this patch vxlan mode was enabled automatically if at least one
>> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
>> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>> 
>> This patch adds support for explicit disabling of vxlan mode via
>> Northbound database.
>> 
>> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>> 
>> CC: Ihar Hrachyshka mailto:ihrac...@redhat.com>>
>> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
>> Signed-off-by: Vladislav Odintsov > >
>> ---
>>  northd/en-global-config.c |  9 +++-
>>  northd/northd.c   | 90 ++-
>>  northd/northd.h   |  6 ++-
>>  ovn-nb.xml| 12 ++
>>  tests/ovn-northd.at    | 29 +
>>  5 files changed, 94 insertions(+), 52 deletions(-)
>> 
>> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
>> index 34e393b33..9310c4575 100644
>> --- a/northd/en-global-config.c
>> +++ b/northd/en-global-config.c
>> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
>> *data)
>>   config_data->svc_monitor_mac);
>>  }
>> 
>> -char *max_tunid = xasprintf("%d",
>> -get_ovn_max_dp_key_local(sbrec_chassis_table));
>> +init_vxlan_mode(>options, sbrec_chassis_table);
>> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>>  smap_replace(options, "max_tunid", max_tunid);
>>  free(max_tunid);
>> 
>> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
>> nbrec_nb_global *nb,
>>  return true;
>>  }
>> 
>> +if (config_out_of_sync(>options, _data->nb_options,
>> +   "disable_vxlan_mode", false)) {
>> +return true;
>> +}
>> +
>>  return false;
>>  }
>> 
>> diff --git a/northd/northd.c b/northd/northd.c
>> index c568f6360..859b233e8 100644
>> --- a/northd/northd.c
>> +++ b/northd/northd.c
>> @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
>>   */
>>  static bool default_acl_drop;
>> 
>> +/* If this option is 'true' northd will use limited 24-bit space for 
>> datapath
>> + * and ports tunnel key allocation (12 bits for each instead of default 
>> 16). */
>> +static bool vxlan_mode;
>> +
>>  #define MAX_OVN_TAGS 4096
>> 
>> 
>> @@ -875,24 +879,31 @@ join_datapaths(const struct nbrec_logical_switch_table 
>> *nbrec_ls_table,
>>  }
>>  }
>> 
>> -static bool
>> -is_vxlan_mode(const struct sbrec_chassis_table *sbrec_chassis_table)
>> +void
>> +init_vxlan_mode(const struct smap *nb_options,
>> +const struct sbrec_chassis_table *sbrec_chassis_table)
>>  {
>> +if (smap_get_bool(nb_options, "disable_vxlan_mode", false)) 

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Ihar Hrachyshka]

Thank you Vladislav.

FYI it was reported in the past in
https://mail.openvswitch.org/pipermail/ovs-discuss/2022-July/051931.html
but fell through cracks then. Thanks for picking it up!

In your patch, you introduce a new config option to disable the
'vxlan-mode' behavior. This will definitely work. But I wonder if we can
automatically detect this scenario by ignoring the chassis that are VTEP
from consideration? I believe ovn-controller-vtep sets `is-vtep` in
other_config, so - would it work if we modify is_vxlan_mode to consider it
too?

Thanks again for looking into this.
Ihar

On Wed, Apr 3, 2024 at 6:34 AM Vladislav Odintsov  wrote:

> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
> for available tunnel IDs because of lack of space in VXLAN VNI.
> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> and 2047 logical switch ports per datapath.
>
> Prior to this patch vxlan mode was enabled automatically if at least one
> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
> only for HW VTEP (RAMP) switch, such limitation makes no sence.
>
> This patch adds support for explicit disabling of vxlan mode via
> Northbound database.
>
> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
>
> CC: Ihar Hrachyshka 
> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
> Signed-off-by: Vladislav Odintsov 
> ---
>  northd/en-global-config.c |  9 +++-
>  northd/northd.c   | 90 ++-
>  northd/northd.h   |  6 ++-
>  ovn-nb.xml| 12 ++
>  tests/ovn-northd.at   | 29 +
>  5 files changed, 94 insertions(+), 52 deletions(-)
>
> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
> index 34e393b33..9310c4575 100644
> --- a/northd/en-global-config.c
> +++ b/northd/en-global-config.c
> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void
> *data)
>   config_data->svc_monitor_mac);
>  }
>
> -char *max_tunid = xasprintf("%d",
> -get_ovn_max_dp_key_local(sbrec_chassis_table));
> +init_vxlan_mode(>options, sbrec_chassis_table);
> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
>  smap_replace(options, "max_tunid", max_tunid);
>  free(max_tunid);
>
> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct
> nbrec_nb_global *nb,
>  return true;
>  }
>
> +if (config_out_of_sync(>options, _data->nb_options,
> +   "disable_vxlan_mode", false)) {
> +return true;
> +}
> +
>  return false;
>  }
>
> diff --git a/northd/northd.c b/northd/northd.c
> index c568f6360..859b233e8 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
>   */
>  static bool default_acl_drop;
>
> +/* If this option is 'true' northd will use limited 24-bit space for
> datapath
> + * and ports tunnel key allocation (12 bits for each instead of default
> 16). */
> +static bool vxlan_mode;
> +
>  #define MAX_OVN_TAGS 4096
>
>
> @@ -875,24 +879,31 @@ join_datapaths(const struct
> nbrec_logical_switch_table *nbrec_ls_table,
>  }
>  }
>
> -static bool
> -is_vxlan_mode(const struct sbrec_chassis_table *sbrec_chassis_table)
> +void
> +init_vxlan_mode(const struct smap *nb_options,
> +const struct sbrec_chassis_table *sbrec_chassis_table)
>  {
> +if (smap_get_bool(nb_options, "disable_vxlan_mode", false)) {
> +vxlan_mode = false;
> +return;
> +}
> +
>  const struct sbrec_chassis *chassis;
>  SBREC_CHASSIS_TABLE_FOR_EACH (chassis, sbrec_chassis_table) {
>  for (int i = 0; i < chassis->n_encaps; i++) {
>  if (!strcmp(chassis->encaps[i]->type, "vxlan")) {
> -return true;
> +vxlan_mode = true;
> +return;
>  }
>  }
>  }
> -return false;
> +vxlan_mode = false;
>  }
>
>  uint32_t
> -get_ovn_max_dp_key_local(const struct sbrec_chassis_table
> *sbrec_chassis_table)
> +get_ovn_max_dp_key_local(void)
>  {
> -if (is_vxlan_mode(sbrec_chassis_table)) {
> +if (vxlan_mode) {
>  /* OVN_MAX_DP_GLOBAL_NUM doesn't apply for vxlan mode. */
>  return OVN_MAX_DP_VXLAN_KEY;
>  }
> @@ -900,15 +911,14 @@ get_ovn_max_dp_key_local(const struct
> sbrec_chassis_table *sbrec_chassis_table)
>  }
>
>  static void
> -ovn_datapath_allocate_key(const struct sbrec_chassis_table
> *sbrec_ch_table,
> -  struct hmap *datapaths, struct hmap *dp_tnlids,
> +ovn_datapath_allocate_key(struct hmap *datapaths, struct hmap *dp_tnlids,
>struct ovn_datapath *od, uint32_t *hint)
>  {
>  if (!od->tunnel_key) {
>  od->tunnel_key = ovn_allocate_tnlid(dp_tnlids, "datapath",
> -OVN_MIN_DP_KEY_LOCAL,
> -
> get_ovn_max_dp_key_local(sbrec_ch_table),
> -

Re: [ovs-dev] [PATCH ovn] northd: Add support for disabling vxlan mode.

[Vladislav Odintsov]

The failed new testcase assumes that patch [1] is applied.
Should I resend them both as a single patchset?

1: 
https://patchwork.ozlabs.org/project/ovn/patch/20240401121510.758326-1-odiv...@gmail.com/

> On 3 Apr 2024, at 13:34, Vladislav Odintsov  wrote:
> 
> Commit [1] introduced a "vxlan mode" concept.  It brought a limitation
> for available tunnel IDs because of lack of space in VXLAN VNI.
> In vxlan mode OVN is limited by 4095 datapaths (LRs or non-transit LSs)
> and 2047 logical switch ports per datapath.
> 
> Prior to this patch vxlan mode was enabled automatically if at least one
> chassis had encap of vxlan type.  In scenarios where one want to use VXLAN
> only for HW VTEP (RAMP) switch, such limitation makes no sence.
> 
> This patch adds support for explicit disabling of vxlan mode via
> Northbound database.
> 
> 0: https://github.com/ovn-org/ovn/commit/b07f1bc3d068
> 
> CC: Ihar Hrachyshka 
> Fixes: b07f1bc3d068 ("Add VXLAN support for non-VTEP datapath bindings")
> Signed-off-by: Vladislav Odintsov 
> ---
> northd/en-global-config.c |  9 +++-
> northd/northd.c   | 90 ++-
> northd/northd.h   |  6 ++-
> ovn-nb.xml| 12 ++
> tests/ovn-northd.at   | 29 +
> 5 files changed, 94 insertions(+), 52 deletions(-)
> 
> diff --git a/northd/en-global-config.c b/northd/en-global-config.c
> index 34e393b33..9310c4575 100644
> --- a/northd/en-global-config.c
> +++ b/northd/en-global-config.c
> @@ -115,8 +115,8 @@ en_global_config_run(struct engine_node *node , void 
> *data)
>  config_data->svc_monitor_mac);
> }
> 
> -char *max_tunid = xasprintf("%d",
> -get_ovn_max_dp_key_local(sbrec_chassis_table));
> +init_vxlan_mode(>options, sbrec_chassis_table);
> +char *max_tunid = xasprintf("%d", get_ovn_max_dp_key_local());
> smap_replace(options, "max_tunid", max_tunid);
> free(max_tunid);
> 
> @@ -523,6 +523,11 @@ check_nb_options_out_of_sync(const struct 
> nbrec_nb_global *nb,
> return true;
> }
> 
> +if (config_out_of_sync(>options, _data->nb_options,
> +   "disable_vxlan_mode", false)) {
> +return true;
> +}
> +
> return false;
> }
> 
> diff --git a/northd/northd.c b/northd/northd.c
> index c568f6360..859b233e8 100644
> --- a/northd/northd.c
> +++ b/northd/northd.c
> @@ -90,6 +90,10 @@ static bool use_ct_inv_match = true;
>  */
> static bool default_acl_drop;
> 
> +/* If this option is 'true' northd will use limited 24-bit space for datapath
> + * and ports tunnel key allocation (12 bits for each instead of default 16). 
> */
> +static bool vxlan_mode;
> +
> #define MAX_OVN_TAGS 4096
> 
> 
> @@ -875,24 +879,31 @@ join_datapaths(const struct nbrec_logical_switch_table 
> *nbrec_ls_table,
> }
> }
> 
> -static bool
> -is_vxlan_mode(const struct sbrec_chassis_table *sbrec_chassis_table)
> +void
> +init_vxlan_mode(const struct smap *nb_options,
> +const struct sbrec_chassis_table *sbrec_chassis_table)
> {
> +if (smap_get_bool(nb_options, "disable_vxlan_mode", false)) {
> +vxlan_mode = false;
> +return;
> +}
> +
> const struct sbrec_chassis *chassis;
> SBREC_CHASSIS_TABLE_FOR_EACH (chassis, sbrec_chassis_table) {
> for (int i = 0; i < chassis->n_encaps; i++) {
> if (!strcmp(chassis->encaps[i]->type, "vxlan")) {
> -return true;
> +vxlan_mode = true;
> +return;
> }
> }
> }
> -return false;
> +vxlan_mode = false;
> }
> 
> uint32_t
> -get_ovn_max_dp_key_local(const struct sbrec_chassis_table 
> *sbrec_chassis_table)
> +get_ovn_max_dp_key_local(void)
> {
> -if (is_vxlan_mode(sbrec_chassis_table)) {
> +if (vxlan_mode) {
> /* OVN_MAX_DP_GLOBAL_NUM doesn't apply for vxlan mode. */
> return OVN_MAX_DP_VXLAN_KEY;
> }
> @@ -900,15 +911,14 @@ get_ovn_max_dp_key_local(const struct 
> sbrec_chassis_table *sbrec_chassis_table)
> }
> 
> static void
> -ovn_datapath_allocate_key(const struct sbrec_chassis_table *sbrec_ch_table,
> -  struct hmap *datapaths, struct hmap *dp_tnlids,
> +ovn_datapath_allocate_key(struct hmap *datapaths, struct hmap *dp_tnlids,
>   struct ovn_datapath *od, uint32_t *hint)
> {
> if (!od->tunnel_key) {
> od->tunnel_key = ovn_allocate_tnlid(dp_tnlids, "datapath",
> -OVN_MIN_DP_KEY_LOCAL,
> -get_ovn_max_dp_key_local(sbrec_ch_table),
> -hint);
> +OVN_MIN_DP_KEY_LOCAL,
> +get_ovn_max_dp_key_local(),
> +hint);
> if (!od->tunnel_key) {
> if (od->sb) {
> sbrec_datapath_binding_delete(od->sb);
> @@ -921,7 +931,6 @@