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=3Ama/SlBbldZHMWwe4U8dLwjz/LSx94ef9IxIV55?=
 =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?=
 =?us-ascii?q?1NksAKh0olCc+BB1f8KavmZio7EcBdXXdu/mqwNg5eH8OtL1A=3D?=
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: AQHV5zp3EYKx17tAz0a8GUB3koLsqQ==
Date:   Wed, 19 Feb 2020 15:37:18 +0000
Message-ID: <20200219153717.GI24043@zorba>
References: <20200217175209.GM24152@zorba>
 <20200217.185235.495219494110132658.davem@davemloft.net>
 <20200218163030.GR24152@zorba>
 <20200218.123546.666027846950664712.davem@davemloft.net>
 <20200218205441.GA24043@zorba>
 <17008791582075176@myt2-508c8f44300a.qloud-c.yandex.net>
In-Reply-To: <17008791582075176@myt2-508c8f44300a.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="iso-8859-1"
Content-ID: <81F008D355FFD5408F2091A0A68B3586@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d9180b29-1883-438a-ec51-08d7b5519a70
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 15:37:18.2705
 (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: N18BQ9EJ0RJE3iOzdsPO28/6LZtf7SzYK86tSPwhiBENAQFD1jzXp8MdJlveIK6K8XPwEe48RSHP3W7D3lhJrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2551
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-10.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 Wed, Feb 19, 2020 at 04:19:36AM +0300, Evgeniy Polyakov wrote:
> 18.02.2020, 23:55, "Daniel Walker (danielwa)" <danielwa@cisco.com>:
> >> =A0> I think I would agree with you if this was unicast, and each list=
ener could tailor
> >> =A0> what messages they want to get. However, this interface isn't tha=
t, and it would
> >> =A0> be considerable work to convert to that.
> >>
> >> =A0You filter at recvmsg() on the specific socket, multicast or not, I
> >> =A0don't understand what the issue is.
> >
> > Cisco tried something like this (I don't know if it was exactly what yo=
ur referring 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 =
could
> > just make a whole new kernel module hooked into netlink sending a diffe=
rent
> > 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.
>=20
> Connector has unicast interface and multicast-like 'subscription', but se=
nding system-wide messages
> implies using broadcast interface, since you can not hold per-user/per-so=
cket information about particular
> event mask, instead you have channels in connector each one could have be=
en used for specific message type,
> but it looks overkill for simple process mask changes.
>=20
> And in fact, now I do not understand your point.
> I thought you have been concerned about receiving too many messages from =
particular connector module because
> there are, for example, too many 'fork/signal' events. And now you want t=
o limit them to 'fork' events only.
> Even if there could be other users who wanted to receive 'signal' and oth=
er events.
=20
This is what I'm looking for, except not fork.

> And you blame connector - basically a network media, call it TCP if you l=
ike - for not filtering this for you?
> And after you have been told to use connector channels - let's call them =
TCP ports -
> which requires quite a bit of work - you do not want to do this (also, th=
is will break backward compatibility for everyone
> else including (!) Cisco (!!)). I'm a little bit lost here.

Maybe I'm confusing connector with cn_proc. Of course I've modified cn_proc=
, and
that's all I'm concern with. If Connector is a larger entity for tranmissio=
n I'm
not concerned with that.

To be honest, I'm not sure where you confusion is coming from. My original =
patch
is what I want, and what i need, and what we're discussing. If David sugges=
ted
something I didn't understand, then maybe we discussing something from two
different perspectives.

> As a side and more practical way - do we want to have a global switch for=
 particular process state changes broadcasting?

I think it would depend if it's likely to have multiple processes listening=
.
Cisco would likely have one process, but there could be a case with contain=
ers
tools where there multiple listeners. I don't know how the containers tools=
 are
using this interface.

Daniel=