All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.