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
Date: Tue, 18 Feb 2020 16:55:03 +0000 [thread overview]
Message-ID: <20200218165502.GS24152@zorba> (raw)
In-Reply-To: <23716871582044372@myt3-4825096bdc88.qloud-c.yandex.net>
On Tue, Feb 18, 2020 at 07:46:12PM +0300, Evgeniy Polyakov wrote:
> 18.02.2020, 19:30, "Daniel Walker (danielwa)" <danielwa@cisco.com>:
>
> > It's multicast and essentially broadcast messages .. So everyone gets every
> > message, and once it's on it's likely it won't be turned off. Given that, 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 could tailor
> > what messages they want to get. However, this interface isn't that, and it would
> > be considerable work to convert to that.
>
> Connector has message/channel ids, you can implement this rate limiting scheme per user/socket.
I don't think I know enough about netlink to do this, but looking at it prior 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 central authority
> which needs or doesn't need some messages? If so, it can not be bad to have a central switch.
>
> 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 would 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
next prev parent reply other threads:[~2020-02-18 16:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 19:29 [PATCH] drivers: connector: cn_proc: allow limiting certain messages Daniel Walker
2020-02-17 2:44 ` David Miller
2020-02-17 17:25 ` Daniel Walker (danielwa)
[not found] ` <16818701581961475@iva7-8a22bc446c12.qloud-c.yandex.net>
2020-02-17 17:52 ` Daniel Walker (danielwa)
2020-02-17 18:32 ` Evgeniy Polyakov
2020-02-18 2:52 ` David Miller
2020-02-18 16:30 ` Daniel Walker (danielwa)
2020-02-18 16:46 ` Evgeniy Polyakov
2020-02-18 16:55 ` Daniel Walker (danielwa) [this message]
2020-02-18 20:35 ` David Miller
2020-02-18 20:54 ` Daniel Walker (danielwa)
2020-02-19 1:19 ` Evgeniy Polyakov
2020-02-19 15:37 ` Daniel Walker (danielwa)
2020-02-18 2:50 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200218165502.GS24152@zorba \
--to=danielwa@cisco.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.