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=3AOwYbOxewGxtzorYfztBzYthIlGMj4e+mNxMJ6p?=
 =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?=
 =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YyU8HclGS1ZN9HCgOk8TE8H7NBWL+C+o4DUfGw?=
 =?us-ascii?q?vyOU9uPuqlRtz0iMK6n6Cq4ZrPbg5UhT27J7RvMBGxqgaXvc4T08NpK706zV?=
 =?us-ascii?q?3CpX4Ad+Nb3ituIk7bkxvn58i29YJulkYYo/878s9cTaj2N781S7BVFnwmNH?=
 =?us-ascii?q?sp/4zm?=
From:   "Daniel Walker (danielwa)" <danielwa@cisco.com>
To:     Evgeniy Polyakov <zbr@ioremap.net>
CC:     David Miller <davem@davemloft.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: AQHV5nwq+DdGQHH8Ek2zcI0YYhqOgA==
Date:   Tue, 18 Feb 2020 16:55:03 +0000
Message-ID: <20200218165502.GS24152@zorba>
References: <20200217172551.GL24152@zorba>
 <16818701581961475@iva7-8a22bc446c12.qloud-c.yandex.net>
 <20200217175209.GM24152@zorba>
 <20200217.185235.495219494110132658.davem@davemloft.net>
 <20200218163030.GR24152@zorba>
 <23716871582044372@myt3-4825096bdc88.qloud-c.yandex.net>
In-Reply-To: <23716871582044372@myt3-4825096bdc88.qloud-c.yandex.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: <494E756B56439D43B1326EC66FCC3D55@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a592d4b-5ab7-4623-9012-08d7b4934cce
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 16:55:03.5963
 (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: 20fMwpdPRT2S1s1Wj+MsXwKMddP+umsDaj4bE2XmsAqruB8cuNBpFCOM42N2kvSOFtnFWd8GB4t2+8VPUGfdkA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3045
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-5.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 07:46:12PM +0300, Evgeniy Polyakov wrote:
> 18.02.2020, 19:30, "Daniel Walker (danielwa)" <danielwa@cisco.com>:
>=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.
> >
> > 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
> Connector has message/channel ids, you can implement this rate limiting s=
cheme per user/socket.

I don't think I know enough about netlink to do this, but looking at it pri=
or to
sending this patch it looked like a fair amount of work.

> This is probably not required if given cn_proc usecase - is it some centr=
al authority
> which needs or doesn't need some messages? If so, it can not be bad to ha=
ve a central switch.
>=20
> But I also heard that container management tools are using this, in this =
case disabling some
> things globally will suddenly break them.

Cisco currently doesn't use this interface at all, the reason is that it's =
too
noisy and we get too many wake-ups. If we did use this interface there woul=
d be
one listener. I would think most embedded use cases would have one listener=
.

Do you know which container management tools are using this ?

Daniel=