From: Harald Welte <laforge@gnumonks.org>
To: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: netdev@vger.kernel.org, osmocom-net-gprs@lists.osmocom.org,
Gabriel Ganne <gabriel.ganne@6wind.com>,
kuba@kernel.org, davem@davemloft.net, pablo@netfilter.org
Subject: Re: [PATCH net-next v2] gtp: add notification mechanism
Date: Thu, 27 Aug 2020 11:00:26 +0200 [thread overview]
Message-ID: <20200827090026.GK130874@nataraja> (raw)
In-Reply-To: <0e2c4c04-a6dc-d081-2bdd-09f8d78607c4@6wind.com>
Hi Nicolas,
On Thu, Aug 27, 2020 at 12:36:24AM +0200, Nicolas Dichtel wrote:
> Le 26/08/2020 à 20:52, Harald Welte a écrit :
> > Wouldn't it make sense to only allocate + fill those messages if we
> > actually knew a subscriber existed?
>
> In fact, this is actually how the netlink framework works.
Well, as you can tell from my responses, I've not been doing kernel work
for a decade now, so I'm looking at things from a more distant and
ignorant perspective. To me it seems odd to allocate memory and copy
data to it (cache misses, ...) if nobody every requested that data, and
nobody will ever use it. But if this is how it is supposed to work,
then I will of course defer to that. All netlink would have to expose
is a function that returns whether or not there are any subscribers
to the given multicast group. Then all of the allocation +
initialization would disappear in a branch that is not executed most of
the time, at least for current, existing gtpnl systems. Yes, that means
one more branch, of course. But that branch will happen later on
anyway, event today: Only after the allocation + initialization.
So having said the above, if this is how it is supposed to work with
netlink:
Acked-by: Harald Welte <laforge@gnumonks.org>
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
next prev parent reply other threads:[~2020-08-27 9:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 14:35 [PATCH net-next] gtp: add notification mechnism Nicolas Dichtel
2020-08-25 15:57 ` [PATCH net-next v2] gtp: add notification mechanism Nicolas Dichtel
2020-08-25 17:01 ` Harald Welte
2020-08-26 7:47 ` Nicolas Dichtel
2020-08-26 18:52 ` Harald Welte
2020-08-26 22:36 ` Nicolas Dichtel
2020-08-27 9:00 ` Harald Welte [this message]
2020-08-27 10:25 ` Nicolas Dichtel
2020-08-27 12:19 ` [PATCH net-next v3] " Nicolas Dichtel
2020-08-27 15:05 ` David Miller
2020-08-27 16:37 ` Nicolas Dichtel
2020-08-27 16:44 ` David Miller
2020-08-27 16:45 ` Nicolas Dichtel
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=20200827090026.GK130874@nataraja \
--to=laforge@gnumonks.org \
--cc=davem@davemloft.net \
--cc=gabriel.ganne@6wind.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=osmocom-net-gprs@lists.osmocom.org \
--cc=pablo@netfilter.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox