From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7B7337BE87 for ; Wed, 20 May 2026 21:48:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.231.154.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779313689; cv=none; b=AdzxR6y07qUiewmwzziFFQ9iLtPZHsij8NaGnmY/EtyZyUz+KtYTrBanKgmJFqHrp5YmxzCXBGn/u6b4v56kDobh2HrMLi1QH94NJ4/jKQfrhg0ClZ3M0nIcSczgcRZ0rwavjx08pnH+77ghmq8oD4ryz9JomRFZ98ktpyCaq0g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779313689; c=relaxed/simple; bh=n9AQjE1hpPxVSJ4m9VEUp01OGG4u8OvAhL1JAAf5J7s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R2doG08vASEePjsu9b3137vErnBScUrqfOGgbeMH4XWvyRyfajOB2zlbzMzTTYXV6aDGWwcaetDY77XIgAuUPTbKOPJTmJ3FBlfwCGGKMM1Erj1Bq5CcqXCVF9fGifWdgLDifpL+6kQiwJs+Y4SJOua6d6+vH2IZ2R9numf9IlY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=candelatech.com; spf=pass smtp.mailfrom=candelatech.com; dkim=pass (1024-bit key) header.d=candelatech.com header.i=@candelatech.com header.b=eq+reY7S; arc=none smtp.client-ip=67.231.154.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=candelatech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=candelatech.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=candelatech.com header.i=@candelatech.com header.b="eq+reY7S" Received: from dispatch1-us1.ppe-hosted.com (ip6-localhost [127.0.0.1]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id D348050AB84 for ; Wed, 20 May 2026 21:48:06 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mail3.candelatech.com (mail.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 913168006F; Wed, 20 May 2026 21:47:59 +0000 (UTC) Received: from [192.168.100.159] (firewall.candelatech.com [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id A813013C2B0; Wed, 20 May 2026 14:47:57 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com A813013C2B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1779313677; bh=n9AQjE1hpPxVSJ4m9VEUp01OGG4u8OvAhL1JAAf5J7s=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eq+reY7SA+XkHWaacHYMAayjx9e5HmPWV81EK1g6mlIrObzjf1y6Skm5BEsRv3rAy kTMmA57+wEKv8N0xrlpYYu2jQGZzlZYsEyrnCujZqRCbGReUP5Nv74N0n4Okm8vnXP QJhfjeGjbWGHg35jdn1rLHX2J+2gfInEIK6PTP5w= Message-ID: Date: Wed, 20 May 2026 14:47:57 -0700 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Using VRF to limit 'ip monitor' and 'iw event' messages Content-Language: en-US To: David Ahern Cc: John-Paul Powers , netdev References: <5e83f1cc-a313-434d-b703-9f020874c03c@candelatech.com> From: Ben Greear Organization: Candela Technologies In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MDID: 1779313680-6febiLok2ZMW X-PPE-STACK: {"stack":"us5"} X-MDID-O: us5;at1;1779313680;6febiLok2ZMW;;13ea00862af1a4a136f3e80d149399ed X-PPE-TRUSTED: V=1;DIR=OUT; On 5/19/26 17:15, David Ahern wrote: > On 5/19/26 8:04 AM, Ben Greear wrote: >> >> At least many ip events are related to a network interface, so we could >> add meta data about that to the netlink msg path and then filter >> before it gets sent to the listener netlink sockets... > > As I recall this problem has been discussed a few times. > > There can be many netlink listeners - e.g., ip monitor, frr, ... > > The lower level code (ie., the one generating the notification) has no > idea how many sockets will receive the message and which ones will want > some filter to be applied to the message before attaching to the socket. > > The higher level code (netlink sockets) has no idea of the content of > the message, so the ability to run a generic filter that is appropriate > for netlink level is really difficult. > >> >> Given a network device, is there an efficient way to get the vrf-id >> to which it belongs? >> > > yes, that is true for ip route, link, neigh, addr, tc, ... not so much > for other netlink users. We have it at least partially working now, it seems like it will not be as bad as I had feared. For our purposes, filtering most of the unwanted messages should be sufficient, and anything we cannot easily figure out the ifindex for, we'll just pass on to the socket. We'll post a patch for consideration once we get some more edge cases sorted out and some more testing completed. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com