From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Haller 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 Message-ID: <8eb1f295bbfe0d662e0df19448e9719be24348f5.camel@redhat.com> References: <51722660f2ef860779e227541dab77046496f135.1535712096.git.lorenzo.bianconi@redhat.com> <1321a4ad-75c5-358f-3a5d-1ec1549a9474@gmail.com> <20180831161902.GD6236@localhost.localdomain> <20180831165444.GE6236@localhost.localdomain> <247de7c5-5046-81f4-d0b9-f6fcd505e8e8@gmail.com> <7153fa4339ebe04d7c3819a8d8eabd789c93753a.camel@redhat.com> <76fe95ba-d80f-e420-1982-97019aa09d7c@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-YkbeTLzBS0XEfkUaExFd" Cc: "David S. Miller" , Network Development To: David Ahern , Lorenzo Bianconi Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44960 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726614AbeIGXez (ORCPT ); Fri, 7 Sep 2018 19:34:55 -0400 In-Reply-To: <76fe95ba-d80f-e420-1982-97019aa09d7c@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: --=-YkbeTLzBS0XEfkUaExFd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 veth that was moved to another netns, and recognize that the peer's=20 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=20 the event is for moving a veth between netns, find the peer in the=20 other netns and recognize that the peer's IFLA_LINK changed. best, THomas --=-YkbeTLzBS0XEfkUaExFd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEESep8Zw4IUOdBlRT2KcI2bk38VygFAluSyO4ACgkQKcI2bk38 VyjbqBAAqRM9lH85TYx6cIn2COc8r1+k7otXKmY9NJF5wAOwvZvKjCgedhWX8X9E dxtloF/XD0v57bzkYH4/zohRJGYNRVZ/EPZBabxo/z2wytzprALtlU/oa4wByM+D CXvByjfp99H2R3E/iwEAFxBOlq3Ka4MP5/CMWLtGb/tq+6PVahLpzqhR1kL1SdCP nSitUXmPRk7PEL8RYhIlK+hlscKqSoC7cQYeC7FEPqV43HafgdB58gl9TaXs9jYM hnCwyqv0/hUkzat1709xWSPTrQsHqaiPtS4RH26/z0zwPRT9WGBgwWQAaWp8aVXq x1PdimKU0UwfmYZisAGep/RhP6FVN0/7h+/4zz7pZucXOjJNd/TjrRgWS5r5gmhn cOy2mgnqYTW5TjC/t/Cx5NzO/OC9uNEe36keIdGXqDJq9ThVlehoUAODEvca30bR ZEuY635pEWy2GjG8+0eWg+JhVizrWxi7Ngh3I5/MB0UzJoaRuiVQA8jbLKCiNpaU gp2VP4cSCR0eDCTAZwezTWeQ4ousFeh/0YZjiRH4Lp7Rn7mSJWsPvnlSqtMmjxmU M+K1b1g7QQ/f95wVL8+JWZT8cNaM0Os2aMaLyaSLd4fCnuQvR4TckiyCsdN+/hOu iWLh/IjVEqvzGGJgqIDzLcudLSHKGQrCQzkvtkNtzOTInaoTQWg= =chRE -----END PGP SIGNATURE----- --=-YkbeTLzBS0XEfkUaExFd--