From: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>
To: Ilya Maximets <i.maximets@ovn.org>, netdev@vger.kernel.org
Cc: dev@openvswitch.org, brauner@kernel.org, edumazet@google.com,
avagin@google.com, alexander.mikhalitsyn@virtuozzo.com,
kuba@kernel.org, pabeni@redhat.com, davem@davemloft.net,
ptikhomirov@virtuozzo.com, Aaron Conole <aconole@redhat.com>
Subject: Re: [ovs-dev] [PATCH net-next 0/1] openvswitch: allow specifying ifindex of new interfaces
Date: Wed, 17 Aug 2022 23:35:14 +0300 [thread overview]
Message-ID: <bc6f197b-37a5-89ea-1311-16f93b5cefed@virtuozzo.com> (raw)
In-Reply-To: <38c9c698-6304-dfa8-7b79-a1cb1e00860b@ovn.org>
On 8/17/22 21:19, Ilya Maximets wrote:
> On 8/17/22 14:49, Andrey Zhadchenko via dev wrote:
>> Hi!
>>
>> CRIU currently do not support checkpoint/restore of OVS configurations, but
>> there was several requests for it. For example,
>> https://github.com/lxc/lxc/issues/2909
>>
>> The main problem is ifindexes of newly created interfaces. We realy need to
>> preserve them after restore. Current openvswitch API does not allow to
>> specify ifindex. Most of the time we can just create an interface via
>> generic netlink requests and plug it into ovs but datapaths (generally any
>> OVS_VPORT_TYPE_INTERNAL) can only be created via openvswitch requests which
>> do not support selecting ifindex.
>
> Hmm. Assuming you restored network interfaces by re-creating them
> on a target system, but I'm curious how do you restore the upcall PID?
> Are you somehow re-creating the netlink socket with the same PID?
> If that will not be done, no traffic will be able to flow through OVS
> anyway until you remove/re-add the port in userspace or re-start OVS.
> Or am I missing something?
>
> Best regards, Ilya Maximets.
Yes, CRIU is able to restore socket nl_pid. We get it via
NDIAG_PROTO_ALL netlink protocol requests (see net/netlink/diag.c)
Upcall pid is exported by get requests via OVS_VPORT_ATTR_UPCALL_PID.
So everything is fine here.
I should note that I did not test *complicated* setups with
ovs-vswitchd, mostly basic ones like veth plugging and several
containers in network. We mainly supported Weave Net k8s SDN which is
based on ovs but do not use its daemon.
Maybe if this is merged and people start use this we will find more
problems with checkpoint/restore, but for now the only problem is
volatile ifindex.
Best regards, Andrey Zhadchenko
>
>>
>> This patch allows to do so.
>> For new datapaths I decided to use dp_infindex in header as infindex
>> because it control ifindex for other requests too.
>> For internal vports I reused OVS_VPORT_ATTR_IFINDEX.
>>
>> The only concern I have is that previously dp_ifindex was not used for
>> OVS_DP_VMD_NEW requests and some software may not set it to zero. However
>> we have been running this patch at Virtuozzo for 2 years and have not
>> encountered this problem. Not sure if it is worth to add new
>> ovs_datapath_attr instead.
>>
>>
>> As a broader solution, another generic approach is possible: modify
>> __dev_change_net_namespace() to allow changing ifindexes within the same
>> netns. Yet we will still need to ignore NETIF_F_NETNS_LOCAL and I am not
>> sure that all its users are ready for ifindex change.
>> This will be indeed better for CRIU so we won't need to change every SDN
>> module to be able to checkpoint/restore it. And probably avoid some bloat.
>> What do you think of this?
>>
>> Andrey Zhadchenko (1):
>> openvswitch: allow specifying ifindex of new interfaces
>>
>> include/uapi/linux/openvswitch.h | 4 ++++
>> net/openvswitch/datapath.c | 16 ++++++++++++++--
>> net/openvswitch/vport-internal_dev.c | 1 +
>> net/openvswitch/vport.h | 2 ++
>> 4 files changed, 21 insertions(+), 2 deletions(-)
>>
>
next prev parent reply other threads:[~2022-08-17 20:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 12:49 [PATCH net-next 0/1] openvswitch: allow specifying ifindex of new interfaces Andrey Zhadchenko
2022-08-17 12:49 ` [PATCH net-next 1/1] " Andrey Zhadchenko
2022-08-17 13:18 ` Christian Brauner
2022-08-17 13:09 ` [PATCH net-next 0/1] " Christian Brauner
2022-08-17 18:19 ` [ovs-dev] " Ilya Maximets
2022-08-17 20:35 ` Andrey Zhadchenko [this message]
2022-08-17 22:15 ` Ilya Maximets
2022-08-17 23:11 ` Andrey Zhadchenko
2022-08-18 11:06 ` Ilya Maximets
2022-08-18 12:26 ` Andrey Zhadchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc6f197b-37a5-89ea-1311-16f93b5cefed@virtuozzo.com \
--to=andrey.zhadchenko@virtuozzo.com \
--cc=aconole@redhat.com \
--cc=alexander.mikhalitsyn@virtuozzo.com \
--cc=avagin@google.com \
--cc=brauner@kernel.org \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=edumazet@google.com \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ptikhomirov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox