[ovs-dev] [PATCH] ofproto: Preserve ofport number for failed ofport across restarts

Ilya Maximets i.maximets at ovn.org
Fri Sep 11 15:06:12 UTC 2020

On 9/11/20 11:13 AM, Vishal Deep Ajmera wrote:
>> Hi, Vishal.  I'm looking through old patches after the patchwork cleanup and
>> it seems that this one in kind of undecided state.
>> Does this patch still valid?
>> Anyway, for the problem you described here:  Maybe it's possible to just use
>> 'ofport_request' configuration option for interfaces?  It could be
>> implemented
>> as picking a unique ofport before adding a new port and set 'ofport_request'
>> along with port creation.  Another way is to fix current ofport for 
>> interfaces
>> once OVS chose it, i.e. port add -> check ofport -> set 'ofport_request' 
>> with
>> that value.
>> In any case after reboot OVS will choose exactly same ofport as it was 
>> before
>> because it is stored in database.
>> What do you think?
> Hi Ilya,
> I agree that using ofp_request at the time of port creation will fix this 
> issue.
> However this means an orchestrator also need to manage unique port
> numbers for ports it is creating on OVS. I am not sure if this is feasible for 
> all.

This solution should not be much harder than below one.  The entity that adds
the port will just need to list port numbers of existing ports and peak any
that is not used yet.

> Also on the other hand if we overload the field ofp_request and set it to ofp 
> number
> automatically assigned by OVS, will it be misleading? However I think this 
> approach is cleaner.

To clarify, I'm talking about ofport_request column in the interface table.
What I'm proposing is that entity that executes port-add command, will later
check the ofport field in the ovsdb and set this value to ofport_request
column for this interface.  Should not be misleading as all operations performed
by the orchestrator, but instead of choosing unused value by itself it will rely
on OVS to to do that.

Best regards, Ilya Maximets.

More information about the dev mailing list