[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200827090026.GK130874@nataraja>
Date: Thu, 27 Aug 2020 11:00:26 +0200
From: Harald Welte <laforge@...monks.org>
To: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc: netdev@...r.kernel.org, osmocom-net-gprs@...ts.osmocom.org,
Gabriel Ganne <gabriel.ganne@...nd.com>, kuba@...nel.org,
davem@...emloft.net, pablo@...filter.org
Subject: Re: [PATCH net-next v2] gtp: add notification mechanism
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@...monks.org>
--
- Harald Welte <laforge@...monks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Powered by blists - more mailing lists