Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
IronPort-PHdr: =?us-ascii?q?9a23=3AYqPi3RF8biwuZc8osM4l0Z1GYnJ96bzpIg4Y7I?=
 =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?=
 =?us-ascii?q?cejNkO2QkpAcqLE0r+efLjaS03GNtLfFRk5Hq8d0NSHZW2ag=3D=3D?=
From:   "Daniel Walker (danielwa)" <danielwa@cisco.com>
To:     David Miller <davem@davemloft.net>
CC:     "zbr@ioremap.net" <zbr@ioremap.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages
Thread-Topic: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages
Thread-Index: AQHV5p2t0fDeU99AI0q9taXpnYkWBg==
Date:   Tue, 18 Feb 2020 20:54:56 +0000
Message-ID: <20200218205441.GA24043@zorba>
References: <20200217175209.GM24152@zorba>
 <20200217.185235.495219494110132658.davem@davemloft.net>
 <20200218163030.GR24152@zorba>
 <20200218.123546.666027846950664712.davem@davemloft.net>
In-Reply-To: <20200218.123546.666027846950664712.davem@davemloft.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: cisco.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B9CAB0FFB9ED6447B9838954E29F7DEF@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 035703d4-1127-467a-d0a5-08d7b4b4cfb1
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 20:54:56.5745
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mygS3wEShQe8jbY6PCyk9pNpcasDnxYP+i2z+sJPJbUT7Swgb+M8qDL4DOpeYATb753J7w2+QlraaSb6s96vpA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2552
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 18, 2020 at 12:35:46PM -0800, David Miller wrote:
> From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
> Date: Tue, 18 Feb 2020 16:30:36 +0000
>=20
> > It's multicast and essentially broadcast messages .. So everyone gets e=
very
> > message, and once it's on it's likely it won't be turned off. Given tha=
t, It seems
> > appropriate that the system administrator has control of what messages =
if any
> > are sent, and it should effect all listening for messages.
> >=20
> > I think I would agree with you if this was unicast, and each listener c=
ould tailor
> > what messages they want to get. However, this interface isn't that, and=
 it would
> > be considerable work to convert to that.
>=20
> You filter at recvmsg() on the specific socket, multicast or not, I
> don't understand what the issue is.

Cisco tried something like this (I don't know if it was exactly what your r=
eferring to),
and it was messy and fairly complicated for a simple interface. In fact it =
was
the first thing I suggested for Cisco.

I'm not sure why Connector has to supply an exact set of messages, one coul=
d
just make a whole new kernel module hooked into netlink sending a different
subset of connector messages. The interface eats up CPU and slows the
system if it's sending messages your just going to ignore. I'm sure the
filtering would also slows down the system.

Daniel=