Message-ID: <20200219153717.GI24043@zorba>
Date:   Wed, 19 Feb 2020 15:37:18 +0000
From:   "Daniel Walker (danielwa)" <danielwa@...co.com>
To:     Evgeniy Polyakov <zbr@...emap.net>
CC:     David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers: connector: cn_proc: allow limiting certain
 messages

On Wed, Feb 19, 2020 at 04:19:36AM +0300, Evgeniy Polyakov wrote:
> 18.02.2020, 23:55, "Daniel Walker (danielwa)" <danielwa@...co.com>:
> >>  > I think I would agree with you if this was unicast, and each listener could tailor
> >>  > what messages they want to get. However, this interface isn't that, and it would
> >>  > be considerable work to convert to that.
> >>
> >>  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 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 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.
> 
> Connector has unicast interface and multicast-like 'subscription', but sending system-wide messages
> implies using broadcast interface, since you can not hold per-user/per-socket information about particular
> event mask, instead you have channels in connector each one could have been used for specific message type,
> but it looks overkill for simple process mask changes.
> 
> 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 to limit them to 'fork' events only.
> Even if there could be other users who wanted to receive 'signal' and other events.
 
This is what I'm looking for, except not fork.

> And you blame connector - basically a network media, call it TCP if you like - 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, this 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 tranmission 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 suggested
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 containers
tools where there multiple listeners. I don't know how the containers tools are
using this interface.

Daniel

Powered by blists - more mailing lists