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
signature.asc
Description: This is a digitally signed message part
