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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
