27 Aug
2020
27 Aug
'20
12:36 a.m.
Le 26/08/2020 à 20:52, Harald Welte a écrit :
Hi Nicolas,
On Wed, Aug 26, 2020 at 09:47:54AM +0200, Nicolas Dichtel wrote:
Ok, thanks for reminding me of that. However, even if those events are
not sent/multicasted, it still looks like the proposed patch is
unconditionally allocating a netlink message and filling it with
information about the PDP. That alone looks like adding significant
overhead to every user - even the majority of current use cases where
nobody is listening/subscribing to that multicast group.
I don't think that
this is a significant overhead. This is added in the control
path. When a PDP context is added, the rtnl lock is took, this is another
magnitude of overhead than a kmalloc().
Sending
(unsolicited) notifications about all of those seems quite heavyweight to me.
There is no 'unsolicited' notifications with this patch. Notifications are sent
only if a userspace application has subscribed to the gtp mcast group.
ip routes or conntrack entries are notified in the same way and there could a
lot of them also (more than 100k conntrack entries for example).
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.