On Wed, Apr 05, 2017 at 02:12:39PM +0000, Ferriter, Cian wrote:
> Hi all,
>
> At the moment in OVS when a port is incorrectly added to a bridge an error is
> usually displayed, either in the logs or on screen. In addition, the port
> shows up in the DB when 'ovs-vsctl show' is executed. This port remains in
> the DB and another port with the same name cannot be added until this port is
> deleted. I have shown an example of this below (where a type of 'dpdkk' is
> given as an error):
>
> $ ovs-vsctl show
> 0a6c5989-7b6c-464f-a100-c7504b8fd5f6
> Bridge "br0"
> Port "br0"
> Interface "br0"
> type: internal
> $ ovs-vsctl --timeout 10 add-port br0 dpdk0 -- set Interface dpdk0 type=dpdkk
> options:dpdk-devargs=0000:07:00.0
> ovs-vsctl: Error detected while setting up 'dpdk0': could not open network
> device dpdk0 (Address family not supported by protocol). See ovs-vswitchd
> log for details.
> ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".
> $ ovs-vsctl show
> 0a6c5989-7b6c-464f-a100-c7504b8fd5f6
> Bridge "br0"
> Port "dpdk0"
> Interface "dpdk0"
> type: dpdkk
> options: {dpdk-devargs="0000:07:00.0"}
> error: "could not open network device dpdk0 (Address family
> not supported by protocol)"
> Port "br0"
> Interface "br0"
> type: internal
> $ ovs-vsctl --timeout 10 add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
> options:dpdk-devargs=0000:07:00.0
> ovs-vsctl: cannot create a port named dpdk0 because a port named dpdk0
> already exists on bridge br0
>
> I just wanted to know if people thought this behavior was appropriate and
> whether the incorrectly added port should remain in the DB. When trying to
> re-add the unsuccessfully created port should the port be blocked because of
> the existing DB entry? Should the broken port be cleaned up from the DB after
> a certain period, or be replaced when the same port is added successfully?
This is the way that OVS has always worked. It's intentional and
desired behavior.
The OVS configuration model is that the database specifies the desired
configuration, then ovs-vswitchd does its best to realize that
configuration. It generally works well, even in cases where races make
devices show up after they've been added to the database or when they
come and go while in the database.
Why does it make sense to configure DPDK ports that won't work? If it
does, then why not remove them after it's clear that they don't work?
That's the strategy I'd expect in such a case.
If you do want to retain the strategy of re-adding dpdk ports sometime
later, then a simple strategy to avoid the problem of ports that might
already exist is to add "--if-exists del-port dpdk0" on the ovs-vsctl
command line before the "add-port" command.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
