This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Nicolas Dichtel nicolas.dichtel at 6wind.comLe 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.