From: Jakub Kicinski <kuba@kernel.org>
To: Xiao Liang <shaw.leon@gmail.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Kuniyuki Iwashima <kuniyu@amazon.com>,
Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH net-next 0/5] net: Improve netns handling in RTNL and ip_tunnel
Date: Wed, 30 Oct 2024 16:35:04 -0700 [thread overview]
Message-ID: <20241030163504.47a375f5@kernel.org> (raw)
In-Reply-To: <CABAhCOQ60u9Bkatbg6bc7CksMTXDw8v06SDsfv77YpEQW+anZg@mail.gmail.com>
On Wed, 30 Oct 2024 10:10:32 +0800 Xiao Liang wrote:
> > Do you think the netns_atomic module param is really necessary?
> > I doubt anyone cares about the event popping up in the wrong
> > name space first.
>
> We used FRRouting in our solution which listens to link notifications to
> set up corresponding objects in userspace. Since the events are sent
> in different namespaces (thus via different RTNL sockets), we can't
> guarantee that the events are received in the correct order, and have
> trouble processing them. The way to solve this problem I can think of is
> to have a multi-netns RTNL socket where all events are synchronized,
> or to eliminate the redundant events in the first place. The latter seems
> easier to implement.
I think we're on the same page. I'm saying that any potential user
will run into a similar problem, and I don't see a clear use case
for notifications in both namespaces. So we can try to make the
behavior of netns_atomic=1 the default one and get rid of the module
param.
next prev parent reply other threads:[~2024-10-30 23:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 2:31 [PATCH net-next 0/5] net: Improve netns handling in RTNL and ip_tunnel Xiao Liang
2024-10-23 2:31 ` [PATCH net-next 1/5] rtnetlink: Lookup device in target netns when creating link Xiao Liang
2024-10-23 3:49 ` Kuniyuki Iwashima
2024-10-23 4:19 ` Xiao Liang
2024-10-23 2:31 ` [PATCH net-next 2/5] rtnetlink: Add netns_atomic flag in rtnl_link_ops Xiao Liang
2024-10-23 4:03 ` Kuniyuki Iwashima
2024-10-23 4:36 ` Xiao Liang
2024-10-23 2:31 ` [PATCH net-next 3/5] net: ip_tunnel: Build flow in underlay net namespace Xiao Liang
2024-10-23 2:31 ` [PATCH net-next 4/5] net: ip_tunnel: Add source netns support for newlink Xiao Liang
2024-10-23 2:31 ` [PATCH net-next 5/5] net: ip_gre: Add netns_atomic module parameter Xiao Liang
2024-10-29 23:17 ` [PATCH net-next 0/5] net: Improve netns handling in RTNL and ip_tunnel Jakub Kicinski
2024-10-30 2:10 ` Xiao Liang
2024-10-30 23:35 ` Jakub Kicinski [this message]
2024-10-31 3:08 ` Xiao Liang
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=20241030163504.47a375f5@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=kuniyu@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shaw.leon@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.