From: Thomas Haller <thaller@redhat.com>
To: David Ahern <dsahern@gmail.com>,
Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace
Date: Fri, 07 Sep 2018 20:52:30 +0200 [thread overview]
Message-ID: <8eb1f295bbfe0d662e0df19448e9719be24348f5.camel@redhat.com> (raw)
In-Reply-To: <76fe95ba-d80f-e420-1982-97019aa09d7c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]
Hi David,
On Mon, 2018-09-03 at 20:54 -0600, David Ahern wrote:
> From init_net:
> $ ip monitor all-nsid
I thought the concern of the patch is the overhead of sending one
additional RTM_NEWLINK message. This workaround has likely higher
overhead. More importantly, it's so cumbersome, that I doubt anybody
would implementing such a solution.
When the events of one namespace are not sufficient to get all relevant
information (local to the namespace itself), the solution is not
monitor all-nsid.
You might save complexity and performance overhead in kernel. But what
you save here is just moved to user-space, which faces higher
complexity (at multiple places/projects, where developers are not
experts in netlink) and higher overhead.
RTM_GETLINK/NLM_F_DUMP allows to fetch information. The same
information is usually also emitted on changes via RTM_NEWLINK
notifications.
Yes, the information may be avilable somehow, but how cumbersome:
a) receive RTM_DELLINK, recognize that the message belongs to a
veth that was moved to another netns, and recognize that the peer's
IFLA_LINK changed. This approach only works when the veth is moved
away from the current namespace.
b) or, enable monitor all-nsid, receive RTM_NEWLINK, recognize that
the event is for moving a veth between netns, find the peer in the
other netns and recognize that the peer's IFLA_LINK changed.
best,
THomas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-09-07 23:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1535712096.git.lorenzo.bianconi@redhat.com>
2018-08-31 11:43 ` [PATCH net-next] veth: report NEWLINK event when moving the peer device in a new namespace Lorenzo Bianconi
2018-08-31 15:24 ` David Ahern
2018-08-31 16:19 ` Lorenzo Bianconi
2018-08-31 16:21 ` David Ahern
2018-08-31 16:54 ` Lorenzo Bianconi
2018-09-01 9:05 ` Lorenzo Bianconi
2018-09-01 23:45 ` David Ahern
2018-09-03 9:10 ` Thomas Haller
2018-09-04 2:54 ` David Ahern
2018-09-07 18:52 ` Thomas Haller [this message]
2018-09-09 1:16 ` David Ahern
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=8eb1f295bbfe0d662e0df19448e9719be24348f5.camel@redhat.com \
--to=thaller@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=lorenzo.bianconi@redhat.com \
--cc=netdev@vger.kernel.org \
/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.