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: >>> 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). > > 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().
> > 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.
