On 25.06.2019 15:20, Flavio Leitner wrote:
> On Tue, Jun 25, 2019 at 01:07:53PM +0300, Ilya Maximets wrote:
>> On 25.06.2019 0:15, Flavio Leitner wrote:
>>> On Mon, Jun 24, 2019 at 06:28:37PM +0300, Ilya Maximets wrote:
>>>> 'netdev' datapath is implemented within ovs-vswitchd process and can
>>>> not exist without it, so it should be gracefully terminated with a
>>>> full cleanup of resources upon ovs-vswitchd exit.
>>>>
>>>> This change forces dpif cleanup for 'netdev' datapath regardless of
>>>> passing '--cleanup' to 'ovs-appctl exit'. Such solution allowes to
>>>> not pass this additional option everytime for userspace datapath
>>>> installations and also allowes to not terminate system datapath in
>>>> setups where both datapaths runs at the same time.
>>>>
>>>> This fixes OVS disappearing from the DPDK point of view (keeping HW
>>>> NICs improperly configured, sudden closing of vhost-user connections)
>>>> and will help with linux devices clearing with upcoming AF_XDP
>>>> netdev support.
>>>
>>> Does this mean that OVS bridges or internal ports will be deleted
>>> from the system regardless of --cleanup parameter?
>>
>> Yes. This will remove all ports and completely destroy userspace datapath.
>>
>> I guess, you're warring about user ip/route settings that could be
>> manually applied to internal ports and not stored in network-scripts
>> or network manager.
>
> Yes!
>
>> I think, that it's not very important case. However, the main goal
>> of this patch is to properly destroy non-internal ports and it could
>> be achieved without loosing user configurations. I'll post v2 with
>> this change.
>
> Thanks to that we can replace/restart OvS without causing major
> disruptions as the configuration remains the same.
>
>
>> BTW, it's system dependent if ip/route information preserved on tap
>> device detaching. I have a few systems, where 'ovs-appctl exit'
>> leads to DOWN state for preserved internal ports and consequently
>> loosing their IP addresses. On a few other systems this doesn't happen.
>
> I haven't seen any bug reports yet related to that. Do you happen to
> know the kernel and OvS versions?
I see this with OVS master and Linux 4.2.6:
# ip addr add 192.168.114.20/24 dev ovsdpdk_br0
# ip addr show dev ovsdpdk_br0
43: ovsdpdk_br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 500
link/ether f2:20:dc:bf:7d:44 brd ff:ff:ff:ff:ff:ff
inet 192.168.114.20/24 scope global ovsdpdk_br0
valid_lft forever preferred_lft forever
# ovs-appctl -t ovs-vswitchd exit
# ip addr show dev ovsdpdk_br0
43: ovsdpdk_br0: <BROADCAST,MULTICAST,PROMISC> mtu 1500 qdisc pfifo_fast state
DOWN group default qlen 500
link/ether f2:20:dc:bf:7d:44 brd ff:ff:ff:ff:ff:ff
The same scenario on RHEL7 keeps the interface in NO-CARRIER,UP state and
preserved ip address.
I don't think that it's OVS. It looks more like a kernel issue.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
